[jira] [Resolved] (TOMEE-2102) IvmContext bind/unbind creates duplicate contexts
[
https://issues.apache.org/jira/browse/TOMEE-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev resolved TOMEE-2102.
--
Resolution: Fixed
Fix Version/s: 7.0.4
Resolving, the pull request was merged a long time ago, but the ticket was
forgotten
> IvmContext bind/unbind creates duplicate contexts
> -
>
> Key: TOMEE-2102
> URL: https://issues.apache.org/jira/browse/TOMEE-2102
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Fix For: 7.0.4
>
>
> Imagine you have the flowing context "a/b/object". The context tree can be
> created in two ways:
> 1. Relative to the root or some
> {code}
> IvmContext root = IvmContext.createRootContext();
> root.bind("a/b/object", new Object);
> {code}
> 2. Relative to some node:
> {code}
> IvmContext root = IvmContext.createRootContext();
> root.bind("a", null);
> IvmContext a = root.lookup("a");
> a.bind("b", null);
> IvmContext b = root.lookup("b")
> a.bind("object", new Object())
> {code}
> So when one looks up "object" or "a" or "b" or object, one has to get the
> very same result regardless if the context tree was created by 1 or by 2. Yet
> this is not the case when it comes to the IvmContext. Maybe the most obvious
> (and shocking) issue is that IvmContext allows to bind 2 different objects to
> the same name ! Example:
> {code}
>IvmContext root = IvmContext.createRootContext();
> root.bind("a/b/object", new Object());
> IvmContext b = (IvmContext) root.lookup("a/b");
> //already bound from root -> must fail, yet it does not
> b.bind("object", new Object());
> {code}
> I've provided various test cases for different combinations of
> bind/unbind/lookup that reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116160#comment-16116160
]
Svetlin Zarev commented on TOMEE-2108:
--
[~rmannibucau] Hi,
The undeploy-on-failure is no really working on tomcat's side, because if the
deployment fails, the app is in STARTING_PREP. So when undeploying from tomcat,
it logs an error and does nothing.
> TomEEContainer (arquillian) does not clean up after failed deployment.
> --
>
> Key: TOMEE-2108
> URL: https://issues.apache.org/jira/browse/TOMEE-2108
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> h4. Problem:
> ---
> When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
> the "archiveName" is not added to "moduleIds". As a result when
> undeploy(Archive) is called, the associated DeployedApp is not found and
> clean up is not performed -> this results in tomcat's internal structures
> still keeping data for the failed webapp, which might break other
> (re)deployments with the same webapp name.
> h4. Steps to reproduce:
> ---
> Execute any of the CDI TCK test that are expected to fail. I tested with
> (passing.xml):
> {code}
>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes1Test"/>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes2Test"/>
>
>
>
> {code}
> The classes are deployed sequentally using the same war name. Both
> deployments will fail as expected. After undeploy is called for teh first
> one, a WARN message is logged:
> {code}
> VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
> undeploy
> WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
> {code}
> So far so good, the deployment failed, so we might assume it was not really
> deployed and dismiss the warning. Unfortunately Tomcat did never perform a
> clean up for that app, so when the next test is deployed (with the same WAR
> name) we can see in the logs:
> {code}
> 04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
> sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
> failed: [javax.naming.OperationNotSupportedException: Context is read only]
> {code}
> That's not what we expected to see. This happens because in
> org.apache.naming.ContextAccessController#setSecurityToken, when the security
> token is being associated with the context name, it checks only if a token
> exists for that name, but not if it's thE same token:
> {code}
> public static void setSecurityToken(Object name, Object token) {
> SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(new RuntimePermission(
> ContextAccessController.class.getName()
> + ".setSecurityToken"));
> }
> if ((!securityTokens.containsKey(name)) && (token != null)) {
> securityTokens.put(name, token);
> }
> }
> {code}
> And the root cause for that is that no clean up was performed (kind of
> related to: TOMEE-2098).
> h4. Proposal:
> ---
> Do clean up if the deployment fails. This would be as simple as adding
> catch(EjbException) in
> org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
> {code}
> } catch (OpenEJBException | EJBException re) { // clean up in undeploy needs
> it
> moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
> re;
> }
> {code}
> Note that I've changed it to use the absolute path, because otherwise the
> ProvisioningResolver is not able to understand the relative path:
> {code}
> 04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
> EjbTransactionUtil.handleSystemException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> java.lang.IllegalArgumentException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
> at
> org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158)
> at
> org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633)
> at
> org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410)
> {code}
> The issue is that the resolver
[jira] [Comment Edited] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116160#comment-16116160
]
Svetlin Zarev edited comment on TOMEE-2108 at 8/7/17 7:04 AM:
--
[~rmannibucau] Hi,
The undeploy-on-failure is no really working on tomcat's side, because if the
deployment fails, the app is still in STARTING_PREP. So when undeploying from
tomcat, it logs an error and does nothing.
was (Author: svetlinzarev):
[~rmannibucau] Hi,
The undeploy-on-failure is no really working on tomcat's side, because if the
deployment fails, the app is in STARTING_PREP. So when undeploying from tomcat,
it logs an error and does nothing.
> TomEEContainer (arquillian) does not clean up after failed deployment.
> --
>
> Key: TOMEE-2108
> URL: https://issues.apache.org/jira/browse/TOMEE-2108
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> h4. Problem:
> ---
> When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
> the "archiveName" is not added to "moduleIds". As a result when
> undeploy(Archive) is called, the associated DeployedApp is not found and
> clean up is not performed -> this results in tomcat's internal structures
> still keeping data for the failed webapp, which might break other
> (re)deployments with the same webapp name.
> h4. Steps to reproduce:
> ---
> Execute any of the CDI TCK test that are expected to fail. I tested with
> (passing.xml):
> {code}
>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes1Test"/>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes2Test"/>
>
>
>
> {code}
> The classes are deployed sequentally using the same war name. Both
> deployments will fail as expected. After undeploy is called for teh first
> one, a WARN message is logged:
> {code}
> VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
> undeploy
> WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
> {code}
> So far so good, the deployment failed, so we might assume it was not really
> deployed and dismiss the warning. Unfortunately Tomcat did never perform a
> clean up for that app, so when the next test is deployed (with the same WAR
> name) we can see in the logs:
> {code}
> 04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
> sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
> failed: [javax.naming.OperationNotSupportedException: Context is read only]
> {code}
> That's not what we expected to see. This happens because in
> org.apache.naming.ContextAccessController#setSecurityToken, when the security
> token is being associated with the context name, it checks only if a token
> exists for that name, but not if it's thE same token:
> {code}
> public static void setSecurityToken(Object name, Object token) {
> SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(new RuntimePermission(
> ContextAccessController.class.getName()
> + ".setSecurityToken"));
> }
> if ((!securityTokens.containsKey(name)) && (token != null)) {
> securityTokens.put(name, token);
> }
> }
> {code}
> And the root cause for that is that no clean up was performed (kind of
> related to: TOMEE-2098).
> h4. Proposal:
> ---
> Do clean up if the deployment fails. This would be as simple as adding
> catch(EjbException) in
> org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
> {code}
> } catch (OpenEJBException | EJBException re) { // clean up in undeploy needs
> it
> moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
> re;
> }
> {code}
> Note that I've changed it to use the absolute path, because otherwise the
> ProvisioningResolver is not able to understand the relative path:
> {code}
> 04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
> EjbTransactionUtil.handleSystemException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> java.lang.IllegalArgumentException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
> at
>
[jira] [Resolved] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev resolved TOMEE-2108.
--
Resolution: Not A Bug
> TomEEContainer (arquillian) does not clean up after failed deployment.
> --
>
> Key: TOMEE-2108
> URL: https://issues.apache.org/jira/browse/TOMEE-2108
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> h4. Problem:
> ---
> When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
> the "archiveName" is not added to "moduleIds". As a result when
> undeploy(Archive) is called, the associated DeployedApp is not found and
> clean up is not performed -> this results in tomcat's internal structures
> still keeping data for the failed webapp, which might break other
> (re)deployments with the same webapp name.
> h4. Steps to reproduce:
> ---
> Execute any of the CDI TCK test that are expected to fail. I tested with
> (passing.xml):
> {code}
>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes1Test"/>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes2Test"/>
>
>
>
> {code}
> The classes are deployed sequentally using the same war name. Both
> deployments will fail as expected. After undeploy is called for teh first
> one, a WARN message is logged:
> {code}
> VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
> undeploy
> WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
> {code}
> So far so good, the deployment failed, so we might assume it was not really
> deployed and dismiss the warning. Unfortunately Tomcat did never perform a
> clean up for that app, so when the next test is deployed (with the same WAR
> name) we can see in the logs:
> {code}
> 04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
> sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
> failed: [javax.naming.OperationNotSupportedException: Context is read only]
> {code}
> That's not what we expected to see. This happens because in
> org.apache.naming.ContextAccessController#setSecurityToken, when the security
> token is being associated with the context name, it checks only if a token
> exists for that name, but not if it's thE same token:
> {code}
> public static void setSecurityToken(Object name, Object token) {
> SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(new RuntimePermission(
> ContextAccessController.class.getName()
> + ".setSecurityToken"));
> }
> if ((!securityTokens.containsKey(name)) && (token != null)) {
> securityTokens.put(name, token);
> }
> }
> {code}
> And the root cause for that is that no clean up was performed (kind of
> related to: TOMEE-2098).
> h4. Proposal:
> ---
> Do clean up if the deployment fails. This would be as simple as adding
> catch(EjbException) in
> org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
> {code}
> } catch (OpenEJBException | EJBException re) { // clean up in undeploy needs
> it
> moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
> re;
> }
> {code}
> Note that I've changed it to use the absolute path, because otherwise the
> ProvisioningResolver is not able to understand the relative path:
> {code}
> 04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
> EjbTransactionUtil.handleSystemException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> java.lang.IllegalArgumentException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
> at
> org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158)
> at
> org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633)
> at
> org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410)
> {code}
> The issue is that the resolver cannot correctly resolve the absolute path
> from the relative one. It thinks it is:
> {code}
>
[jira] [Commented] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116152#comment-16116152
]
Svetlin Zarev commented on TOMEE-2108:
--
Given my previous comment, I don't think that TomEEContainer can actually do
the clean up. The proper solution would be the Tomcat WebAppBuilder to properly
clean up after failed deployment -> TOMEE-2098
> TomEEContainer (arquillian) does not clean up after failed deployment.
> --
>
> Key: TOMEE-2108
> URL: https://issues.apache.org/jira/browse/TOMEE-2108
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> h4. Problem:
> ---
> When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
> the "archiveName" is not added to "moduleIds". As a result when
> undeploy(Archive) is called, the associated DeployedApp is not found and
> clean up is not performed -> this results in tomcat's internal structures
> still keeping data for the failed webapp, which might break other
> (re)deployments with the same webapp name.
> h4. Steps to reproduce:
> ---
> Execute any of the CDI TCK test that are expected to fail. I tested with
> (passing.xml):
> {code}
>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes1Test"/>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes2Test"/>
>
>
>
> {code}
> The classes are deployed sequentally using the same war name. Both
> deployments will fail as expected. After undeploy is called for teh first
> one, a WARN message is logged:
> {code}
> VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
> undeploy
> WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
> {code}
> So far so good, the deployment failed, so we might assume it was not really
> deployed and dismiss the warning. Unfortunately Tomcat did never perform a
> clean up for that app, so when the next test is deployed (with the same WAR
> name) we can see in the logs:
> {code}
> 04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
> sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
> failed: [javax.naming.OperationNotSupportedException: Context is read only]
> {code}
> That's not what we expected to see. This happens because in
> org.apache.naming.ContextAccessController#setSecurityToken, when the security
> token is being associated with the context name, it checks only if a token
> exists for that name, but not if it's thE same token:
> {code}
> public static void setSecurityToken(Object name, Object token) {
> SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(new RuntimePermission(
> ContextAccessController.class.getName()
> + ".setSecurityToken"));
> }
> if ((!securityTokens.containsKey(name)) && (token != null)) {
> securityTokens.put(name, token);
> }
> }
> {code}
> And the root cause for that is that no clean up was performed (kind of
> related to: TOMEE-2098).
> h4. Proposal:
> ---
> Do clean up if the deployment fails. This would be as simple as adding
> catch(EjbException) in
> org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
> {code}
> } catch (OpenEJBException | EJBException re) { // clean up in undeploy needs
> it
> moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
> re;
> }
> {code}
> Note that I've changed it to use the absolute path, because otherwise the
> ProvisioningResolver is not able to understand the relative path:
> {code}
> 04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
> EjbTransactionUtil.handleSystemException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> java.lang.IllegalArgumentException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
> at
> org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158)
> at
> org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633)
> at
> org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410)
> {code}
> The issue is that the resolver cannot
[jira] [Comment Edited] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116137#comment-16116137
]
Svetlin Zarev edited comment on TOMEE-2108 at 8/7/17 6:44 AM:
--
Even if the DeployerEjb is given the correct moduleId/path, it still won't be
able to clean up, because, Assembler.deployedApplications will not contain
AppInfo for the failed deployment.
was (Author: svetlinzarev):
Even if the DeployerEjb is given the correct moduleId/path, it still won't be
able to clean up, because, Assembler.deployedApplications will not contain an
entry for the failed deployment.
> TomEEContainer (arquillian) does not clean up after failed deployment.
> --
>
> Key: TOMEE-2108
> URL: https://issues.apache.org/jira/browse/TOMEE-2108
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> h4. Problem:
> ---
> When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
> the "archiveName" is not added to "moduleIds". As a result when
> undeploy(Archive) is called, the associated DeployedApp is not found and
> clean up is not performed -> this results in tomcat's internal structures
> still keeping data for the failed webapp, which might break other
> (re)deployments with the same webapp name.
> h4. Steps to reproduce:
> ---
> Execute any of the CDI TCK test that are expected to fail. I tested with
> (passing.xml):
> {code}
>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes1Test"/>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes2Test"/>
>
>
>
> {code}
> The classes are deployed sequentally using the same war name. Both
> deployments will fail as expected. After undeploy is called for teh first
> one, a WARN message is logged:
> {code}
> VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
> undeploy
> WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
> {code}
> So far so good, the deployment failed, so we might assume it was not really
> deployed and dismiss the warning. Unfortunately Tomcat did never perform a
> clean up for that app, so when the next test is deployed (with the same WAR
> name) we can see in the logs:
> {code}
> 04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
> sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
> failed: [javax.naming.OperationNotSupportedException: Context is read only]
> {code}
> That's not what we expected to see. This happens because in
> org.apache.naming.ContextAccessController#setSecurityToken, when the security
> token is being associated with the context name, it checks only if a token
> exists for that name, but not if it's thE same token:
> {code}
> public static void setSecurityToken(Object name, Object token) {
> SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(new RuntimePermission(
> ContextAccessController.class.getName()
> + ".setSecurityToken"));
> }
> if ((!securityTokens.containsKey(name)) && (token != null)) {
> securityTokens.put(name, token);
> }
> }
> {code}
> And the root cause for that is that no clean up was performed (kind of
> related to: TOMEE-2098).
> h4. Proposal:
> ---
> Do clean up if the deployment fails. This would be as simple as adding
> catch(EjbException) in
> org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
> {code}
> } catch (OpenEJBException | EJBException re) { // clean up in undeploy needs
> it
> moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
> re;
> }
> {code}
> Note that I've changed it to use the absolute path, because otherwise the
> ProvisioningResolver is not able to understand the relative path:
> {code}
> 04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
> EjbTransactionUtil.handleSystemException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> java.lang.IllegalArgumentException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
> at
>
[jira] [Commented] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116137#comment-16116137
]
Svetlin Zarev commented on TOMEE-2108:
--
Even if the DeployerEjb is given the correct moduleId/path, it still won't be
able to clean up, because, Assembler.deployedApplications will not contain an
entry for the failed deployment.
> TomEEContainer (arquillian) does not clean up after failed deployment.
> --
>
> Key: TOMEE-2108
> URL: https://issues.apache.org/jira/browse/TOMEE-2108
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> h4. Problem:
> ---
> When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
> the "archiveName" is not added to "moduleIds". As a result when
> undeploy(Archive) is called, the associated DeployedApp is not found and
> clean up is not performed -> this results in tomcat's internal structures
> still keeping data for the failed webapp, which might break other
> (re)deployments with the same webapp name.
> h4. Steps to reproduce:
> ---
> Execute any of the CDI TCK test that are expected to fail. I tested with
> (passing.xml):
> {code}
>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes1Test"/>
>
>name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes2Test"/>
>
>
>
> {code}
> The classes are deployed sequentally using the same war name. Both
> deployments will fail as expected. After undeploy is called for teh first
> one, a WARN message is logged:
> {code}
> VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
> undeploy
> WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
> {code}
> So far so good, the deployment failed, so we might assume it was not really
> deployed and dismiss the warning. Unfortunately Tomcat did never perform a
> clean up for that app, so when the next test is deployed (with the same WAR
> name) we can see in the logs:
> {code}
> 04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
> sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
> failed: [javax.naming.OperationNotSupportedException: Context is read only]
> {code}
> That's not what we expected to see. This happens because in
> org.apache.naming.ContextAccessController#setSecurityToken, when the security
> token is being associated with the context name, it checks only if a token
> exists for that name, but not if it's thE same token:
> {code}
> public static void setSecurityToken(Object name, Object token) {
> SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(new RuntimePermission(
> ContextAccessController.class.getName()
> + ".setSecurityToken"));
> }
> if ((!securityTokens.containsKey(name)) && (token != null)) {
> securityTokens.put(name, token);
> }
> }
> {code}
> And the root cause for that is that no clean up was performed (kind of
> related to: TOMEE-2098).
> h4. Proposal:
> ---
> Do clean up if the deployment fails. This would be as simple as adding
> catch(EjbException) in
> org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
> {code}
> } catch (OpenEJBException | EJBException re) { // clean up in undeploy needs
> it
> moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
> re;
> }
> {code}
> Note that I've changed it to use the absolute path, because otherwise the
> ProvisioningResolver is not able to understand the relative path:
> {code}
> 04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
> EjbTransactionUtil.handleSystemException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> java.lang.IllegalArgumentException: Not a local file but no prefix
> specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
> can't resolve
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
> at
> org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
> at
> org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158)
> at
> org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633)
> at
> org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410)
> {code}
> The issue is that the resolver cannot correctly
[jira] [Updated] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2108:
-
Description:
h4. Problem:
---
When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
the "archiveName" is not added to "moduleIds". As a result when
undeploy(Archive) is called, the associated DeployedApp is not found and clean
up is not performed -> this results in tomcat's internal structures still
keeping data for the failed webapp, which might break other (re)deployments
with the same webapp name.
h4. Steps to reproduce:
---
Execute any of the CDI TCK test that are expected to fail. I tested with
(passing.xml):
{code}
{code}
The classes are deployed sequentally using the same war name. Both deployments
will fail as expected. After undeploy is called for teh first one, a WARN
message is logged:
{code}
VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
undeploy
WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
{code}
So far so good, the deployment failed, so we might assume it was not really
deployed and dismiss the warning. Unfortunately Tomcat did never perform a
clean up for that app, so when the next test is deployed (with the same WAR
name) we can see in the logs:
{code}
04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
failed: [javax.naming.OperationNotSupportedException: Context is read only]
{code}
That's not what we expected to see. This happens because in
org.apache.naming.ContextAccessController#setSecurityToken, when the security
token is being associated with the context name, it checks only if a token
exists for that name, but not if it's thE same token:
{code}
public static void setSecurityToken(Object name, Object token) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new RuntimePermission(
ContextAccessController.class.getName()
+ ".setSecurityToken"));
}
if ((!securityTokens.containsKey(name)) && (token != null)) {
securityTokens.put(name, token);
}
}
{code}
And the root cause for that is that no clean up was performed (kind of related
to: TOMEE-2098).
h4. Proposal:
---
Do clean up if the deployment fails. This would be as simple as adding
catch(EjbException) in
org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
{code}
} catch (OpenEJBException | EJBException re) { // clean up in undeploy needs it
moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
re;
}
{code}
Note that I've changed it to use the absolute path, because otherwise the
ProvisioningResolver is not able to understand the relative path:
{code}
04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
EjbTransactionUtil.handleSystemException: Not a local file but no prefix
specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
can't resolve
java.lang.IllegalArgumentException: Not a local file but no prefix specified:
target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So can't resolve
at
org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
at
org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
at
org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158)
at
org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633)
at
org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410)
{code}
The issue is that the resolver cannot correctly resolve the absolute path from
the relative one. It thinks it is:
{code}
/home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/tomee/apache-tomee-plus-7.0.4-SNAPSHOT/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war
{code}
While it really is:
{code}
/home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war
{code}
h4. Summary
---
* when the deployment fails, no clean up is done
* do clean up after failed deplyments
** catch javax.ejb.EjbException besides OpenEjbException
** Use absolute path for DeployedApp.path in case of failed deployment
What do you think ?
was:
h4. Problem:
---
When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
the "archiveName" is not added to "moduleIds". As a result when
undeploy(Archive) is called, the associated DeployedApp is not found and clean
up is not performed -> this results in tomcat's internal
[jira] [Updated] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2108:
-
Description:
h4. Problem:
---
When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
the "archiveName" is not added to "moduleIds". As a result when
undeploy(Archive) is called, the associated DeployedApp is not found and clean
up is not performed -> this results in tomcat's internal structures still
keeping data for the failed webapp, which might break other (re)deployments
with the same webapp name.
h4. Steps to reproduce:
---
Execute any of the CDI TCK test that are expected to fail. I tested with
(passing.xml):
{code}
{code}
The classes are deployed sequentally using the same war name. Both deployments
will fail as expected. After undeploy is called for teh first one, a WARN
message is logged:
{code}
VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
undeploy
WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
{code}
So far so good, the deployment failed, so we might assume it was not really
deployed and dismiss the warning. Unfortunately Tomcat did never perform a
clean up for that app, so when the next test is deployed (with the same WAR
name) we can see in the logs:
{code}
04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
failed: [javax.naming.OperationNotSupportedException: Context is read only]
{code}
That's not what we expected to see. This happens because in
org.apache.naming.ContextAccessController#setSecurityToken, when the security
token is being associated with the context name, it checks only if a token
exists for that name, but not if it's thE same token:
{code}
public static void setSecurityToken(Object name, Object token) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new RuntimePermission(
ContextAccessController.class.getName()
+ ".setSecurityToken"));
}
if ((!securityTokens.containsKey(name)) && (token != null)) {
securityTokens.put(name, token);
}
}
{code}
And the root cause for that is that no clean up was performed (kind of related
to: TOMEE-2098).
h4. Proposal:
---
Do clean up if the deployment fails. This would be as simple as adding
catch(EjbException) in
org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
{code}
} catch (OpenEJBException | EJBException re) { // clean up in undeploy needs it
moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
re;
}
{code}
Note that I've changed it to use the absolute path, because otherwise the
ProvisioningResolver is not able to understand the relative path:
{code}
04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
EjbTransactionUtil.handleSystemException: Not a local file but no prefix
specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
can't resolve
java.lang.IllegalArgumentException: Not a local file but no prefix specified:
target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So can't resolve
at
org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
at
org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
at
org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158)
at
org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633)
at
org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410)
{code}
The issue is that the resolver cannot correctly resolve the absolute path. It
thinks it is:
{code}
/home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/tomee/apache-tomee-plus-7.0.4-SNAPSHOT/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war
{code}
While it really is:
{code}
/home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war
{code}
h4. Summary
---
* when the deployment fails, no clean up is done
* do clean up after failed deplyments
** catch javax.ejb.EjbException besides OpenEjbException
** Use absolute path for DeployedApp.path in case of failed deployment
What do you think ?
was:
h4. Problem:
---
When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
the "archiveName" is not added to "moduleIds". As a result when
undeploy(Archive) is called, the associated DeployedApp is not found and clean
up is not performed -> this results in tomcat's internal strucutures still
keeping
[jira] [Updated] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2108:
-
Description:
h4. Problem:
---
When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
the "archiveName" is not added to "moduleIds". As a result when
undeploy(Archive) is called, the associated DeployedApp is not found and clean
up is not performed -> this results in tomcat's internal strucutures still
keeping data for the faild webapp, which might break other (re)deployments wuth
the same webapp name.
h4. Steps to reproduce:
---
Execute any of the CDI TCK test that are expected to fail. I tested with
(passing.xml):
{code}
{code}
The classes are deployed sequentally using the same war name. Both deployments
will fail as expected. After undeploy is called for teh first one, a WARN
message is logged:
{code}
VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
undeploy
WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
{code}
So far so good, the deployment faild, so we might assume it was not really
deployed and dismiss the warning. Unfortunately Tomcat did never perform a
clean up for that app, so when the next test is deployed (with the same WAR
name) we can see in the logs:
{code}
04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
failed: [javax.naming.OperationNotSupportedException: Context is read only]
{code}
That's not what we expected to see. This happens because in
org.apache.naming.ContextAccessController#setSecurityToken, when the security
token is being associated with the context name, it checks only if a token
exists for that name, but not if it's thE same token:
{code}
public static void setSecurityToken(Object name, Object token) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new RuntimePermission(
ContextAccessController.class.getName()
+ ".setSecurityToken"));
}
if ((!securityTokens.containsKey(name)) && (token != null)) {
securityTokens.put(name, token);
}
}
{code}
And the root cause for that is that no clean up was performed (kind of related
to: TOMEE-2098).
h4. Proposal:
---
Do clean up if the deployment fails. This would be as simple as adding
catch(EjbException) in
org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
{code}
} catch (OpenEJBException | EJBException re) { // clean up in undeploy needs it
moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
re;
}
{code}
Note that I've changed it to use the absolute path, because otherwise the
ProvisioningResolver is not able to understand the relative path:
{code}
04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
EjbTransactionUtil.handleSystemException: Not a local file but no prefix
specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
can't resolve
java.lang.IllegalArgumentException: Not a local file but no prefix specified:
target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So can't resolve
at
org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
at
org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
at
org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158)
at
org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633)
at
org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410)
{code}
The issue is that the resolver cannot correctly resolve the absolute path. It
thinks it is:
{code}
/home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/tomee/apache-tomee-plus-7.0.4-SNAPSHOT/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war
{code}
While it really is:
{code}
/home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war
{code}
h4. Summary
---
* when the deployment fails, no clean up is done
* do clean up after failed deplyments
** catch javax.ejb.EjbException besides OpenEjbException
** Use absolute path for DeployedApp.path in case of failed deployment
What do you think ?
was:
h4. Problem:
---
When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
the "archiveName" is not added to "moduleIds". As a result when
undeploy(Archive) is called, the associated DeployedApp is not found and clean
up is not performed -> this results in tomcat's internal strucutures still
keeping
[jira] [Created] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
Svetlin Zarev created TOMEE-2108:
Summary: TomEEContainer (arquillian) does not clean up after
failed deployment.
Key: TOMEE-2108
URL: https://issues.apache.org/jira/browse/TOMEE-2108
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
h4. Problem:
---
When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and
the "archiveName" is not added to "moduleIds". As a result when
undeploy(Archive) is called, the associated DeployedApp is not found and clean
up is not performed -> this results in tomcat's internal strucutures still
keeping data for the faild webapp, which might break other (re)deployments wuth
the same webapp name.
h4. Steps to reproduce:
---
Execute any of the CDI TCK test that are expected to fail. I tested with
(passing.xml):
{code}
{code}
The classes are deployed sequentally using the same war name. Both deployments
will fail as expected. After undeploy is called for teh first one, a WARN
message is logged:
{code}
VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer
undeploy
WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed
{code}
So far so good, the deployment faild, so we might assume it was not really
deployed and dismiss the warning. Unfortunately Tomcat did never perform a
clean up for that app, so when the next test is deployed (with the same WAR
name) we can see in the logs:
{code}
04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5]
sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context
failed: [javax.naming.OperationNotSupportedException: Context is read only]
{code}
That's not what we expected to see. This happens because in
org.apache.naming.ContextAccessController#setSecurityToken, when the security
token is being associated with the context name, it checks only if a token
exists for that name, but not if it's thE same token:
{code}
public static void setSecurityToken(Object name, Object token) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new RuntimePermission(
ContextAccessController.class.getName()
+ ".setSecurityToken"));
}
if ((!securityTokens.containsKey(name)) && (token != null)) {
securityTokens.put(name, token);
}
}
{code}
And the root cause for that is that no clean up was performed (kind of related
to: TOMEE-2098).
h4. Proposal:
---
Do clean up if the deployment fails. This would be as simple as adding
catch(EjbException) in
org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive):
} catch (OpenEJBException | EJBException re) { // clean up in undeploy needs it
moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file));
re;
}
{code}
Note that I've changed it to use the absolute path, because otherwise the
ProvisioningResolver is not able to understand the relative path:
{code}
04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9]
org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException
EjbTransactionUtil.handleSystemException: Not a local file but no prefix
specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So
can't resolve
java.lang.IllegalArgumentException: Not a local file but no prefix specified:
target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So can't resolve
at
org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133)
at
org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115)
at
org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158)
at
org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633)
at
org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410)
{code}
The issue is that the resolver cannot correctly resolve the absolute path. It
thinks it is:
{code}
/home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/tomee/apache-tomee-plus-7.0.4-SNAPSHOT/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war
{code}
While it really is:
{code}
/home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war
{code}
h4. Summary
---
* when the deployment fails, no clean up is done
* do clean up after failed deplyments
** catch javax.ejb.EjbException besides OpenEjbException
** Use absolute path for DeployedApp.path in case of failed deployment
What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (TOMEE-2103) [Embedded TomEE] CDI should be enabled by default
[
https://issues.apache.org/jira/browse/TOMEE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev resolved TOMEE-2103.
--
Resolution: Won't Fix
This makes sense. Thanks!
> [Embedded TomEE] CDI should be enabled by default
> -
>
> Key: TOMEE-2103
> URL: https://issues.apache.org/jira/browse/TOMEE-2103
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: org.example.zip
>
>
> Since JavaEE7 CDI should be enabled by default (i.e. it should not require
> beans.xml)
> Expected output of the attached app (or when beans.xml is present):
> {code}
> AroundConstruct: before
> constructor
> AroundConstruct: after
> post-construct
> AroundInvoke: before
> work
> AroundInvoke: after
> {code}
> Actual output:
> {code}
> constructor
> post-construct
> AroundInvoke: before
> work
> AroundInvoke: after
> {code}
> As you can see the @AroundConstruct is not invoked. This happens only in the
> case of embedded tomee
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TOMEE-2103) [Embedded TomEE] CDI should be enabled by default
[
https://issues.apache.org/jira/browse/TOMEE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101701#comment-16101701
]
Svetlin Zarev commented on TOMEE-2103:
--
This happens because DeploymentLoader::discoverModuleType classifies the app as
EjbModule, but (default, empty) beans.xml is added (to altDD) only if the app
is classified either as WebModule or AppModule.
> [Embedded TomEE] CDI should be enabled by default
> -
>
> Key: TOMEE-2103
> URL: https://issues.apache.org/jira/browse/TOMEE-2103
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: org.example.zip
>
>
> Since JavaEE7 CDI should be enabled by default (i.e. it should not require
> beans.xml)
> Expected output of the attached app (or when beans.xml is present):
> {code}
> AroundConstruct: before
> constructor
> AroundConstruct: after
> post-construct
> AroundInvoke: before
> work
> AroundInvoke: after
> {code}
> Actual output:
> {code}
> constructor
> post-construct
> AroundInvoke: before
> work
> AroundInvoke: after
> {code}
> As you can see the @AroundConstruct is not invoked. This happens only in the
> case of embedded tomee
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2103) [Embedded TomEE] CDI should be enabled by default
Svetlin Zarev created TOMEE-2103:
Summary: [Embedded TomEE] CDI should be enabled by default
Key: TOMEE-2103
URL: https://issues.apache.org/jira/browse/TOMEE-2103
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Attachments: org.example.zip
Since JavaEE7 CDI should be enabled by default (i.e. it should not require
beans.xml)
Expected output of the attached app (or when beans.xml is present):
{code}
AroundConstruct: before
constructor
AroundConstruct: after
post-construct
AroundInvoke: before
work
AroundInvoke: after
{code}
Actual output:
{code}
constructor
post-construct
AroundInvoke: before
work
AroundInvoke: after
{code}
As you can see the @AroundConstruct is not invoked. This happens only in the
case of embedded tomee
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2102) IvmContext bind/unbind creates duplicate contexts
[
https://issues.apache.org/jira/browse/TOMEE-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2102:
-
Description:
Imagine you have the flowing context "a/b/object". The context tree can be
created in two ways:
1. Relative to the root or some
{code}
IvmContext root = IvmContext.createRootContext();
root.bind("a/b/object", new Object);
{code}
2. Relative to some node:
{code}
IvmContext root = IvmContext.createRootContext();
root.bind("a", null);
IvmContext a = root.lookup("a");
a.bind("b", null);
IvmContext b = root.lookup("b")
a.bind("object", new Object())
{code}
So when one looks up "object" or "a" or "b" or object, one has to get the very
same result regardless if the context tree was created by 1 or by 2. Yet this
is not the case when it comes to the IvmContext. Maybe the most obvious (and
shocking) issue is that IvmContext allows to bind 2 different objects to the
same name ! Example:
{code}
IvmContext root = IvmContext.createRootContext();
root.bind("a/b/object", new Object());
IvmContext b = (IvmContext) root.lookup("a/b");
//already bound from root -> must fail, yet it does not
b.bind("object", new Object());
{code}
I've provided various test cases for different combinations of
bind/unbind/lookup that reproduce the issue.
was:
Imagine you have the flowing context "a/b/object". The context tree can be
created in two ways:
1. Relative to the root or some
{code}
IvmContext root = IvmContext.createRootContext();
root.bind("a/b/object", new Object);
{code}
2. Relative to some node:
IvmContext root = IvmContext.createRootContext();
root.bind("a", null);
IvmContext a = root.lookup("a");
a.bind("b", null);
IvmContext b = root.lookup("b")
a.bind("object", new Object())
{code}
So when one looks up "object" or "a" or "b" or object, one has to get the very
same result regardless if the context tree was created by 1 or by 2. Yet this
is not the case when it comes to the IvmContext. Maybe the most obvious (and
shocking) issue is that IvmContext allows to bind 2 different objects to the
same name ! Example:
{code}
IvmContext root = IvmContext.createRootContext();
root.bind("a/b/object", new Object());
IvmContext b = (IvmContext) root.lookup("a/b");
//already bound from root -> must fail, yet it does not
b.bind("object", new Object());
{code}
I've provided various test cases for different combinations of
bind/unbind/lookup that reproduce the issue.
> IvmContext bind/unbind creates duplicate contexts
> -
>
> Key: TOMEE-2102
> URL: https://issues.apache.org/jira/browse/TOMEE-2102
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> Imagine you have the flowing context "a/b/object". The context tree can be
> created in two ways:
> 1. Relative to the root or some
> {code}
> IvmContext root = IvmContext.createRootContext();
> root.bind("a/b/object", new Object);
> {code}
> 2. Relative to some node:
> {code}
> IvmContext root = IvmContext.createRootContext();
> root.bind("a", null);
> IvmContext a = root.lookup("a");
> a.bind("b", null);
> IvmContext b = root.lookup("b")
> a.bind("object", new Object())
> {code}
> So when one looks up "object" or "a" or "b" or object, one has to get the
> very same result regardless if the context tree was created by 1 or by 2. Yet
> this is not the case when it comes to the IvmContext. Maybe the most obvious
> (and shocking) issue is that IvmContext allows to bind 2 different objects to
> the same name ! Example:
> {code}
>IvmContext root = IvmContext.createRootContext();
> root.bind("a/b/object", new Object());
> IvmContext b = (IvmContext) root.lookup("a/b");
> //already bound from root -> must fail, yet it does not
> b.bind("object", new Object());
> {code}
> I've provided various test cases for different combinations of
> bind/unbind/lookup that reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2102) IvmContext bind/unbind creates duplicate contexts
Svetlin Zarev created TOMEE-2102:
Summary: IvmContext bind/unbind creates duplicate contexts
Key: TOMEE-2102
URL: https://issues.apache.org/jira/browse/TOMEE-2102
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Imagine you have the flowing context "a/b/object". The context tree can be
created in two ways:
1. Relative to the root or some
{code}
IvmContext root = IvmContext.createRootContext();
root.bind("a/b/object", new Object);
{code}
2. Relative to some node:
IvmContext root = IvmContext.createRootContext();
root.bind("a", null);
IvmContext a = root.lookup("a");
a.bind("b", null);
IvmContext b = root.lookup("b")
a.bind("object", new Object())
{code}
So when one looks up "object" or "a" or "b" or object, one has to get the very
same result regardless if the context tree was created by 1 or by 2. Yet this
is not the case when it comes to the IvmContext. Maybe the most obvious (and
shocking) issue is that IvmContext allows to bind 2 different objects to the
same name ! Example:
{code}
IvmContext root = IvmContext.createRootContext();
root.bind("a/b/object", new Object());
IvmContext b = (IvmContext) root.lookup("a/b");
//already bound from root -> must fail, yet it does not
b.bind("object", new Object());
{code}
I've provided various test cases for different combinations of
bind/unbind/lookup that reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2098) TomcatWebAppBuilder does not correctly handle the case when startInternal(StandardContext) fails
Svetlin Zarev created TOMEE-2098:
Summary: TomcatWebAppBuilder does not correctly handle the case
when startInternal(StandardContext) fails
Key: TOMEE-2098
URL: https://issues.apache.org/jira/browse/TOMEE-2098
Project: TomEE
Issue Type: Bug
Affects Versions: 7.0.3, 7.0.4
Reporter: Svetlin Zarev
Attachments: cditest.war
If the application configuration fails in
TomcatWebAppBuilder.startInternal(StandardContext) (see the attached
application), the web app builder tries to "undeploy" the app, but this
operation can never succeed because the StandardContext is in state
STARTING_PREP, while this operation requires it to be in one of NEW,
INITIALIZED, FAILED, BEFORE_DESTROY_EVENT, STOPPED (see LifecycleBase:288). As
a result tomcat logs an error:
{code}
An invalid Lifecycle transition was attempted ([before_destroy]) for component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/cditest]] in
state [STARTING_PREP]
{code}
and undeploy basically does nothing. And if one tries to **redeploy** the app,
the operation will fail because tomcat would not have cleaned up after itself.
The correct way to handle this case would be to mark the StandardContext as
unconfigured -> this will make StandardContext move into LifecycleState.FAILED
after it process the lifecycle listeners and do proper clean up.
Here is PoC of my proposal:
https://github.com/apache/tomee/compare/master...SvetlinZarev:ctxFailsToStart
What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2073) In some cases the EJB.beanName() is not processed
[ https://issues.apache.org/jira/browse/TOMEE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svetlin Zarev updated TOMEE-2073: - Fix Version/s: 7.0.4 > In some cases the EJB.beanName() is not processed > - > > Key: TOMEE-2073 > URL: https://issues.apache.org/jira/browse/TOMEE-2073 > Project: TomEE > Issue Type: Bug >Reporter: Svetlin Zarev > Fix For: 7.0.4 > > > In some cases the EJB.beanName() is not processed, which results in incorrect > bean resolution. > For instance in the test case from the PR, the ejb-jar descriptor should > complement the information from the EJB annotation. What actually happens is > that the value from the bean name attribute gets ignored, and a wrong bean > gets injected as a result -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2057:
-
Fix Version/s: 7.0.4
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Fix For: 7.0.4
>
> Attachments: sample-v2.zip, sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = ;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
> throw new IllegalStateException("Entity not persisted in
> TX_REQUIRED");
> }
> }
> }
> {code}
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TOMEE-2087) IvmContext.list() does not correctly list the context content
[
https://issues.apache.org/jira/browse/TOMEE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080084#comment-16080084
]
Svetlin Zarev commented on TOMEE-2087:
--
Hi, my tests passed. Should I open a thread in the mailing list ?
> IvmContext.list() does not correctly list the context content
> -
>
> Key: TOMEE-2087
> URL: https://issues.apache.org/jira/browse/TOMEE-2087
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>Priority: Critical
> Attachments: sample.zip
>
>
> MyNamingEnumeration.gatherNodes() adds the wrong federated context entries in
> the result set (related to TOMEE-2086 - it was indeed a typo, but we "fixed"
> it with the wrong NameNode).
> Another issue is with MyNamingEnumeration.isMyChild() which considers entries
> that are NOT children to the "parent" tree as such
> One more issue is that the wrong parentNode is passed as argument to
> gatherNodes in case we are listing the context for any "IvmContext != this"
> To give an example:
> Expected context content:
> {code}
> ### Context: /module
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
> [looking up: TestEJB!org.example.TestEJB] [Value]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
> [looking up: TestEJB] [Value]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: ModuleName Class=java.lang.String [looking up: ModuleName]
> [Value]:
> Name: env Class=org.apache.naming.NamingContext [looking up: env]
> [Value]: org.apache.naming.NamingContext@1bb2d0a8
> ### Context: /module/env
> Name: nameClass=java.lang.String [looking up: name] [Value]:
> module-env
> {code}
> Actual context content:
> {code}
> ### Context: /module
> Name: global Class=org.apache.openejb.core.ivm.naming.IvmContext
> [looking up: global]> Failed to lookup: global
> Name: dummy Class=java.lang.String [looking up: dummy] > Failed to
> lookup: dummy
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: ModuleName Class=java.lang.String [looking up: ModuleName]
> [Value]:
> Name: env Class=org.apache.openejb.core.ivm.naming.IvmContext
> [looking up: env] [Value]: IvmContext{mynode=}
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> ### Context: /module/env
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] > Failed to lookup:
> TestEJB!org.example.TestEJB
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] > Failed to lookup: TestEJB
> Name: nameClass=java.lang.String [looking up: name] [Value]:
> module-env
> {code}
> Note the "failed too lookup..." messages - these are all objects that MUST
> NOT be listed as part of that context.
> I'm attaching an application that reproduces the issue.
> Requesting it like "http://localhost:8080/?ejb; will print tomee's naming tree
> Requesting it like "http://localhost:8080; will print tomcat's naming tree
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2087) IvmContext.list() does not correctly list the context content
[
https://issues.apache.org/jira/browse/TOMEE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2087:
-
Description:
MyNamingEnumeration.gatherNodes() adds the wrong federated context entries in
the result set (related to TOMEE-2086 - it was indeed a typo, but we "fixed" it
with the wrong NameNode).
Another issue is with MyNamingEnumeration.isMyChild() which considers entries
that are NOT children to the "parent" tree as such
One more issue is that the wrong parentNode is passed as argument to
gatherNodes in case we are listing the context for any "IvmContext != this"
To give an example:
Expected context content:
{code}
### Context: /module
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB!org.example.TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.naming.NamingContext [looking up: env]
[Value]: org.apache.naming.NamingContext@1bb2d0a8
### Context: /module/env
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Actual context content:
{code}
### Context: /module
Name: globalClass=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: global]> Failed to lookup: global
Name: dummy Class=java.lang.String [looking up: dummy] > Failed to
lookup: dummy
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: env] [Value]: IvmContext{mynode=}
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
### Context: /module/env
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] > Failed to lookup:
TestEJB!org.example.TestEJB
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] > Failed to lookup: TestEJB
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Note the "failed too lookup..." messages - these are all objects that MUST NOT
be listed as part of that context.
I'm attaching an application that reproduces the issue.
Requesting it like "http://localhost:8080/?ejb; will print tomee's naming tree
Requesting it like "http://localhost:8080; will print tomcat's naming tree
was:
MyNamingEnumeration.gatherNodes() adds the wrong federated context entries in
the result set (related to TOMEE-2086 - it was indeed a typo, but we "fixed" it
with the wrong NameNode).
The other issue is with MyNamingEnumeration.isMyChild() which considers entries
that are NOT children to the "parent" tree as such
To give an example:
Expected context content:
{code}
### Context: /module
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB!org.example.TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.naming.NamingContext [looking up: env]
[Value]: org.apache.naming.NamingContext@1bb2d0a8
### Context: /module/env
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Actual context content:
{code}
### Context: /module
Name: globalClass=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: global]> Failed to
[jira] [Commented] (TOMEE-2087) IvmContext.list() does not correctly list the context content
[
https://issues.apache.org/jira/browse/TOMEE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079621#comment-16079621
]
Svetlin Zarev commented on TOMEE-2087:
--
Here are the necessary changes to fix the list() operation, but I'd still need
to run my tests in order to make sure I didn't break something.
https://github.com/apache/tomee/compare/master...SvetlinZarev:tomee-2087?diff=unified=tomee-2087
> IvmContext.list() does not correctly list the context content
> -
>
> Key: TOMEE-2087
> URL: https://issues.apache.org/jira/browse/TOMEE-2087
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>Priority: Critical
> Attachments: sample.zip
>
>
> MyNamingEnumeration.gatherNodes() adds the wrong federated context entries in
> the result set (related to TOMEE-2086 - it was indeed a typo, but we "fixed"
> it with the wrong NameNode).
> The other issue is with MyNamingEnumeration.isMyChild() which considers
> entries that are NOT children to the "parent" tree as such
> To give an example:
> Expected context content:
> {code}
> ### Context: /module
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
> [looking up: TestEJB!org.example.TestEJB] [Value]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
> [looking up: TestEJB] [Value]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: ModuleName Class=java.lang.String [looking up: ModuleName]
> [Value]:
> Name: env Class=org.apache.naming.NamingContext [looking up: env]
> [Value]: org.apache.naming.NamingContext@1bb2d0a8
> ### Context: /module/env
> Name: nameClass=java.lang.String [looking up: name] [Value]:
> module-env
> {code}
> Actual context content:
> {code}
> ### Context: /module
> Name: global Class=org.apache.openejb.core.ivm.naming.IvmContext
> [looking up: global]> Failed to lookup: global
> Name: dummy Class=java.lang.String [looking up: dummy] > Failed to
> lookup: dummy
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: ModuleName Class=java.lang.String [looking up: ModuleName]
> [Value]:
> Name: env Class=org.apache.openejb.core.ivm.naming.IvmContext
> [looking up: env] [Value]: IvmContext{mynode=}
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> ### Context: /module/env
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] > Failed to lookup:
> TestEJB!org.example.TestEJB
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] > Failed to lookup: TestEJB
> Name: nameClass=java.lang.String [looking up: name] [Value]:
> module-env
> {code}
> Note the "failed too lookup..." messages - these are all objects that MUST
> NOT be listed as part of that context.
> I'm attaching an application that reproduces the issue.
> Requesting it like "http://localhost:8080/?ejb; will print tomee's naming tree
> Requesting it like "http://localhost:8080; will print tomcat's naming tree
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2087) IvmContext.list() does not correctly list the context content
[
https://issues.apache.org/jira/browse/TOMEE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2087:
-
Description:
MyNamingEnumeration.gatherNodes() adds the wrong federated context entries in
the result set (related to TOMEE-2086 - it was indeed a typo, but we "fixed" it
with the wrong NameNode).
The other issue is with MyNamingEnumeration.isMyChild() which considers entries
that are NOT children to the "parent" tree as such
To give an example:
Expected context content:
{code}
### Context: /module
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB!org.example.TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.naming.NamingContext [looking up: env]
[Value]: org.apache.naming.NamingContext@1bb2d0a8
### Context: /module/env
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Actual context content:
{code}
### Context: /module
Name: globalClass=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: global]> Failed to lookup: global
Name: dummy Class=java.lang.String [looking up: dummy] > Failed to
lookup: dummy
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: env] [Value]: IvmContext{mynode=}
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
### Context: /module/env
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] > Failed to lookup:
TestEJB!org.example.TestEJB
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] > Failed to lookup: TestEJB
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Note the "failed too lookup..." messages - these are all objects that MUST NOT
be listed as part of that context.
I'm attaching an application that reproduces the issue.
Requesting it like "http://localhost:8080/?ejb; will print tomee's naming tree
Requesting it like "http://localhost:8080; will print tomcat's naming tree
was:
NameNode has some weird logic based on comparing hash codes, which determines
if the object has to be bound in lessTree, grtrTree, etc. The issue is that it
does not work correctly and binds the objects in the wrong contexts. For
instance if lessTree/grtrTree is not null and is a NameNode representing a
subcontext, it will bind the object to that subcontext which is incorrect.
Context.lookup() seems to work because NameNode's bind()/resolve() follow the
same logic, but if you inspect the naming context with Context.list() - which
returns the correct information about the subcontexts, you'll see that some
contexts have more name class pairs than they should.
To give an example:
Expected context content:
{code}
### Context: /module
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB!org.example.TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.naming.NamingContext [looking up: env]
[Value]: org.apache.naming.NamingContext@1bb2d0a8
### Context: /module/env
Name: name Class=java.lang.String
[jira] [Updated] (TOMEE-2087) IvmContext.list() does not correctly list the context content
[
https://issues.apache.org/jira/browse/TOMEE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2087:
-
Summary: IvmContext.list() does not correctly list the context content
(was: TomEE's naming binds objects in wrong contexts)
> IvmContext.list() does not correctly list the context content
> -
>
> Key: TOMEE-2087
> URL: https://issues.apache.org/jira/browse/TOMEE-2087
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>Priority: Critical
> Attachments: sample.zip
>
>
> NameNode has some weird logic based on comparing hash codes, which
> determines if the object has to be bound in lessTree, grtrTree, etc. The
> issue is that it does not work correctly and binds the objects in the wrong
> contexts. For instance if lessTree/grtrTree is not null and is a NameNode
> representing a subcontext, it will bind the object to that subcontext which
> is incorrect.
> Context.lookup() seems to work because NameNode's bind()/resolve() follow the
> same logic, but if you inspect the naming context with Context.list() - which
> returns the correct information about the subcontexts, you'll see that some
> contexts have more name class pairs than they should.
> To give an example:
> Expected context content:
> {code}
> ### Context: /module
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
> [looking up: TestEJB!org.example.TestEJB] [Value]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
> [looking up: TestEJB] [Value]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: ModuleName Class=java.lang.String [looking up: ModuleName]
> [Value]:
> Name: env Class=org.apache.naming.NamingContext [looking up: env]
> [Value]: org.apache.naming.NamingContext@1bb2d0a8
> ### Context: /module/env
> Name: nameClass=java.lang.String [looking up: name] [Value]:
> module-env
> {code}
> Actual context content:
> {code}
> ### Context: /module
> Name: global Class=org.apache.openejb.core.ivm.naming.IvmContext
> [looking up: global]> Failed to lookup: global
> Name: dummy Class=java.lang.String [looking up: dummy] > Failed to
> lookup: dummy
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: ModuleName Class=java.lang.String [looking up: ModuleName]
> [Value]:
> Name: env Class=org.apache.openejb.core.ivm.naming.IvmContext
> [looking up: env] [Value]: IvmContext{mynode=}
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] [Reference]:
> proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
> ### Context: /module/env
> Name: TestEJB!org.example.TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB!org.example.TestEJB] > Failed to lookup:
> TestEJB!org.example.TestEJB
> Name: TestEJB
> Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
> [looking up: TestEJB] > Failed to lookup: TestEJB
> Name: nameClass=java.lang.String [looking up: name] [Value]:
> module-env
> {code}
> Note the "failed too lookup..." messages - these are all objects that MUST
> NOT be bound in that context.
> I'm attaching an application that reproduces the issue.
> Requesting it like "http://localhost:8080/?ejb; will print tomee's naming tree
> Requesting it like "http://localhost:8080; will print tomcat's naming tree
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2086) InitialContext.list() fails with NPE when called from EJB
[
https://issues.apache.org/jira/browse/TOMEE-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2086:
-
Fix Version/s: 7.0.4
> InitialContext.list() fails with NPE when called from EJB
> -
>
> Key: TOMEE-2086
> URL: https://issues.apache.org/jira/browse/TOMEE-2086
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.4
>Reporter: Svetlin Zarev
> Fix For: 7.0.4
>
> Attachments: sample.zip
>
>
> InitialContext.list() fails with NPE when called from EJB. The same works
> from servlet. Attached application (with source) that reproduces the issue
> {code}
> ### Context:
> java.lang.NullPointerException: while trying to invoke the method
> org.apache.openejb.core.ivm.naming.NameNode$Federation.iterator() of a null
> object returned from java.lang.Class.cast(java.lang.Object)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:586)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.(IvmContext.java:574)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyListEnumeration.(IvmContext.java:545)
> at
> org.apache.openejb.core.ivm.naming.IvmContext.list(IvmContext.java:381)
> at
> org.apache.openejb.core.ivm.naming.ContextWrapper.list(ContextWrapper.java:117)
> at
> org.apache.tomee.catalina.OpenEJBContext.list(OpenEJBContext.java:121)
> at org.apache.naming.SelectorContext.list(SelectorContext.java:359)
> at javax.naming.InitialContext.list(InitialContext.java:461)
> at org.example.TestServlet.listContext(TestServlet.java:48)
> at org.example.TestEJB.printContexts(TestEJB.java:14)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:181)
> at
> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
> at
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:347)
> at
> org.example.TestEJB$$LocalBeanProxy.printContexts(org/example/TestEJB.java)
> at org.example.TestServlet.doGet(TestServlet.java:27)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>
[jira] [Resolved] (TOMEE-2086) InitialContext.list() fails with NPE when called from EJB
[
https://issues.apache.org/jira/browse/TOMEE-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev resolved TOMEE-2086.
--
Resolution: Fixed
> InitialContext.list() fails with NPE when called from EJB
> -
>
> Key: TOMEE-2086
> URL: https://issues.apache.org/jira/browse/TOMEE-2086
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.4
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> InitialContext.list() fails with NPE when called from EJB. The same works
> from servlet. Attached application (with source) that reproduces the issue
> {code}
> ### Context:
> java.lang.NullPointerException: while trying to invoke the method
> org.apache.openejb.core.ivm.naming.NameNode$Federation.iterator() of a null
> object returned from java.lang.Class.cast(java.lang.Object)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:586)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.(IvmContext.java:574)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyListEnumeration.(IvmContext.java:545)
> at
> org.apache.openejb.core.ivm.naming.IvmContext.list(IvmContext.java:381)
> at
> org.apache.openejb.core.ivm.naming.ContextWrapper.list(ContextWrapper.java:117)
> at
> org.apache.tomee.catalina.OpenEJBContext.list(OpenEJBContext.java:121)
> at org.apache.naming.SelectorContext.list(SelectorContext.java:359)
> at javax.naming.InitialContext.list(InitialContext.java:461)
> at org.example.TestServlet.listContext(TestServlet.java:48)
> at org.example.TestEJB.printContexts(TestEJB.java:14)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:181)
> at
> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
> at
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:347)
> at
> org.example.TestEJB$$LocalBeanProxy.printContexts(org/example/TestEJB.java)
> at org.example.TestServlet.doGet(TestServlet.java:27)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
>
[jira] [Updated] (TOMEE-2087) TomEE's naming binds objects in wrong contexts
[
https://issues.apache.org/jira/browse/TOMEE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2087:
-
Description:
NameNode has some weird logic based on comparing hash codes, which determines
if the object has to be bound in lessTree, grtrTree, etc. The issue is that it
does not work correctly and binds the objects in the wrong contexts. For
instance if lessTree/grtrTree is not null and is a NameNode representing a
subcontext, it will bind the object to that subcontext which is incorrect.
Context.lookup() seems to work because NameNode's bind()/resolve() follow the
same logic, but if you inspect the naming context with Context.list() - which
returns the correct information about the subcontexts, you'll see that some
contexts have more name class pairs than they should.
To give an example:
Expected context content:
{code}
### Context: /module
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB!org.example.TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.naming.NamingContext [looking up: env]
[Value]: org.apache.naming.NamingContext@1bb2d0a8
### Context: /module/env
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Actual context content:
{code}
### Context: /module
Name: globalClass=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: global]> Failed to lookup: global
Name: dummy Class=java.lang.String [looking up: dummy] > Failed to
lookup: dummy
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: env] [Value]: IvmContext{mynode=}
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
### Context: /module/env
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] > Failed to lookup:
TestEJB!org.example.TestEJB
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] > Failed to lookup: TestEJB
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Note the "failed too lookup..." messages - these are all objects that MUST NOT
be bound in that context.
I'm attaching an application that reproduces the issue.
Requesting it like "http://localhost:8080/?ejb; will print tomee's naming tree
Requesting it like "http://localhost:8080; will print tomcat's naming tree
was:
NameNode has some weird logic based on comparing hash codes, which determines
if the object has to be bound in lessTree, grtrTree, etc. The issue is that it
does not work correctly and binds the objects in the wrong contexts. For
instance if lessTree/grtrTree is not null and is a NameNode representing a
subcontext, it will bind the object to that subcontext which is incorrect.
Context.lookup() seems to work because NameNode's bind()/resolve() follow the
same logic, but if you inspect the naming context with Context.list() - which
returns the correct information about the subcontexts, you'll see that some
contexts have more name class pairs than should.
To give an example:
Expected context content:
{code}
### Context: /module
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB!org.example.TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB] [Value]:
[jira] [Created] (TOMEE-2087) TomEE's naming binds objects in wrong contexts
Svetlin Zarev created TOMEE-2087:
Summary: TomEE's naming binds objects in wrong contexts
Key: TOMEE-2087
URL: https://issues.apache.org/jira/browse/TOMEE-2087
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Priority: Critical
Attachments: sample.zip
NameNode has some weird logic based on comparing hash codes, which determines
if the object has to be bound in lessTree, grtrTree, etc. The issue is that it
does not work correctly and binds the objects in the wrong contexts. For
instance if lessTree/grtrTree is not null and is a NameNode representing a
subcontext, it will bind the object to that subcontext which is incorrect.
Context.lookup() seems to work because NameNode's bind()/resolve() follow the
same logic, but if you inspect the naming context with Context.list() - which
returns the correct information about the subcontexts, you'll see that some
contexts have more name class pairs than should.
To give an example:
Expected context content:
{code}
### Context: /module
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB!org.example.TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.assembler.classic.JndiBuilder$ContextualEjbLookup
[looking up: TestEJB] [Value]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.naming.NamingContext [looking up: env]
[Value]: org.apache.naming.NamingContext@1bb2d0a8
### Context: /module/env
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Actual context content:
{code}
### Context: /module
Name: globalClass=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: global]> Failed to lookup: global
Name: dummy Class=java.lang.String [looking up: dummy] > Failed to
lookup: dummy
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: ModuleNameClass=java.lang.String [looking up: ModuleName]
[Value]:
Name: env Class=org.apache.openejb.core.ivm.naming.IvmContext
[looking up: env] [Value]: IvmContext{mynode=}
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] [Reference]:
proxy=org.example.TestEJB;deployment=ROOT//TestEJB;pk=null
### Context: /module/env
Name: TestEJB!org.example.TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB!org.example.TestEJB] > Failed to lookup:
TestEJB!org.example.TestEJB
Name: TestEJB
Class=org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference
[looking up: TestEJB] > Failed to lookup: TestEJB
Name: name Class=java.lang.String [looking up: name] [Value]:
module-env
{code}
Note the "failed too lookup..." messages - these are all objects that MUST NOT
be bound in that context.
I'm attaching an application that reproduces the issue.
Requesting it like "http://localhost:8080/?ejb; will print tomee's naming tree
Requesting it like "http://localhost:8080; will print tomcat's naming tree
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TOMEE-2086) InitialContext.list() fails with NPE when called from EJB
[
https://issues.apache.org/jira/browse/TOMEE-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074434#comment-16074434
]
Svetlin Zarev commented on TOMEE-2086:
--
you are right, it should be "node", the code above is checking if node is
Federation, but later casts "initiallyRequestedNode" to Federation.
> InitialContext.list() fails with NPE when called from EJB
> -
>
> Key: TOMEE-2086
> URL: https://issues.apache.org/jira/browse/TOMEE-2086
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.4
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> InitialContext.list() fails with NPE when called from EJB. The same works
> from servlet. Attached application (with source) that reproduces the issue
> {code}
> ### Context:
> java.lang.NullPointerException: while trying to invoke the method
> org.apache.openejb.core.ivm.naming.NameNode$Federation.iterator() of a null
> object returned from java.lang.Class.cast(java.lang.Object)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:586)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.(IvmContext.java:574)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyListEnumeration.(IvmContext.java:545)
> at
> org.apache.openejb.core.ivm.naming.IvmContext.list(IvmContext.java:381)
> at
> org.apache.openejb.core.ivm.naming.ContextWrapper.list(ContextWrapper.java:117)
> at
> org.apache.tomee.catalina.OpenEJBContext.list(OpenEJBContext.java:121)
> at org.apache.naming.SelectorContext.list(SelectorContext.java:359)
> at javax.naming.InitialContext.list(InitialContext.java:461)
> at org.example.TestServlet.listContext(TestServlet.java:48)
> at org.example.TestEJB.printContexts(TestEJB.java:14)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:181)
> at
> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
> at
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:347)
> at
> org.example.TestEJB$$LocalBeanProxy.printContexts(org/example/TestEJB.java)
> at org.example.TestServlet.doGet(TestServlet.java:27)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
> at
>
[jira] [Commented] (TOMEE-2086) InitialContext.list() fails with NPE when called from EJB
[
https://issues.apache.org/jira/browse/TOMEE-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074388#comment-16074388
]
Svetlin Zarev commented on TOMEE-2086:
--
I'm not familiar with TomEE's naming impl, so I'm not sure if my "solution" is
OK, but a simple check for "null" seems to fix it (IvmContext:586):
{code}
final Object initiallyRequestedNodeObject = initiallyRequestedNode.getObject();
if (null != initiallyRequestedNodeObject) {
{code}
> InitialContext.list() fails with NPE when called from EJB
> -
>
> Key: TOMEE-2086
> URL: https://issues.apache.org/jira/browse/TOMEE-2086
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.4
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> InitialContext.list() fails with NPE when called from EJB. The same works
> from servlet. Attached application (with source) that reproduces the issue
> {code}
> ### Context:
> java.lang.NullPointerException: while trying to invoke the method
> org.apache.openejb.core.ivm.naming.NameNode$Federation.iterator() of a null
> object returned from java.lang.Class.cast(java.lang.Object)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:586)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.(IvmContext.java:574)
> at
> org.apache.openejb.core.ivm.naming.IvmContext$MyListEnumeration.(IvmContext.java:545)
> at
> org.apache.openejb.core.ivm.naming.IvmContext.list(IvmContext.java:381)
> at
> org.apache.openejb.core.ivm.naming.ContextWrapper.list(ContextWrapper.java:117)
> at
> org.apache.tomee.catalina.OpenEJBContext.list(OpenEJBContext.java:121)
> at org.apache.naming.SelectorContext.list(SelectorContext.java:359)
> at javax.naming.InitialContext.list(InitialContext.java:461)
> at org.example.TestServlet.listContext(TestServlet.java:48)
> at org.example.TestEJB.printContexts(TestEJB.java:14)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:181)
> at
> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
> at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
> at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
> at
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:347)
> at
> org.example.TestEJB$$LocalBeanProxy.printContexts(org/example/TestEJB.java)
> at org.example.TestServlet.doGet(TestServlet.java:27)
> at
[jira] [Created] (TOMEE-2086) InitialContext.list() fails with NPE when called from EJB
Svetlin Zarev created TOMEE-2086:
Summary: InitialContext.list() fails with NPE when called from EJB
Key: TOMEE-2086
URL: https://issues.apache.org/jira/browse/TOMEE-2086
Project: TomEE
Issue Type: Bug
Components: TomEE Core Server
Affects Versions: 7.0.4
Reporter: Svetlin Zarev
Attachments: sample.zip
InitialContext.list() fails with NPE when called from EJB. The same works from
servlet. Attached application (with source) that reproduces the issue
{code}
### Context:
java.lang.NullPointerException: while trying to invoke the method
org.apache.openejb.core.ivm.naming.NameNode$Federation.iterator() of a null
object returned from java.lang.Class.cast(java.lang.Object)
at
org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:586)
at
org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
at
org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
at
org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.addInListIfNeeded(IvmContext.java:608)
at
org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.gatherNodes(IvmContext.java:582)
at
org.apache.openejb.core.ivm.naming.IvmContext$MyNamingEnumeration.(IvmContext.java:574)
at
org.apache.openejb.core.ivm.naming.IvmContext$MyListEnumeration.(IvmContext.java:545)
at
org.apache.openejb.core.ivm.naming.IvmContext.list(IvmContext.java:381)
at
org.apache.openejb.core.ivm.naming.ContextWrapper.list(ContextWrapper.java:117)
at
org.apache.tomee.catalina.OpenEJBContext.list(OpenEJBContext.java:121)
at org.apache.naming.SelectorContext.list(SelectorContext.java:359)
at javax.naming.InitialContext.list(InitialContext.java:461)
at org.example.TestServlet.listContext(TestServlet.java:48)
at org.example.TestEJB.printContexts(TestEJB.java:14)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
at
org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:181)
at
org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
at
org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:85)
at
org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:252)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:212)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:347)
at
org.example.TestEJB$$LocalBeanProxy.printContexts(org/example/TestEJB.java)
at org.example.TestServlet.doGet(TestServlet.java:27)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Created] (TOMEE-2085) AutoConfig::firstMatching sorting issue with java 8
Svetlin Zarev created TOMEE-2085:
Summary: AutoConfig::firstMatching sorting issue with java 8
Key: TOMEE-2085
URL: https://issues.apache.org/jira/browse/TOMEE-2085
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Java 8 changed the implementation of Collections.sort(). In java < 8 it always
allocated a new array which was used for the actual sorting, and then the list
was recreated with it's content. Starting with Jav a8, the sort() method
delegates to the concrete implementation of the concrete list. For arrya list
it works directly on the backing array, which violates the assumption of the
current comparator impl, that the backing array is not modified during the
actual sorting.
Test case
{code}
public final class Main {
public static void main(String[] args) {
final Random random = new Random();
final String prefix = "0";
for (int k = 0; k < 1000; k++) {
try {
final List resourceIds = generateRandomData(random);
sort(prefix, resourceIds);
} catch (Exception e) {
System.out.println(e);
break;
}
System.out.println(k);
}
}
private static void sort(final String prefix, final List
resourceIds) {
Collections.sort(resourceIds, new Comparator() { // sort from
webapp to global resources
@Override
public int compare(final String o1, final String o2) { // don't
change global order, just put app scoped resource before others
if (o1.startsWith(prefix) && o2.startsWith(prefix)) {
return resourceIds.indexOf(o1) - resourceIds.indexOf(o2);
} else if (o1.startsWith(prefix)) {
return -1;
} else if (o2.startsWith(prefix)) {
return 1;
}
// make it stable with prefixed comparison + keep existing
ordering (bck compat)
return resourceIds.indexOf(o1) - resourceIds.indexOf(o2);
}
});
}
private static List generateRandomData(Random random) {
final List resourceIds = new ArrayList<>();
for (int i = 0; i < 5000; i++) {
resourceIds.add(Integer.toString(random.nextInt(3)) +
random.nextInt(1000));
}
return resourceIds;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2074) TomcatWebAppBuilder does not correctly set NamingContextListener.setExceptionOnFailedWrite()
[
https://issues.apache.org/jira/browse/TOMEE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2074:
-
Description:
The TomcatWebAppBuilder does not correctly set the
NamingContextListener.setExceptionOnFailedWrite() property - it always sets the
default value which is "true", instead of the one specified in the context.xml
---
*Execution flow:*
1. TomcatWebAppBuilder:890 creates new NamingContextLisener
2. TomcatWebAppBuilder sets the "exceptionOnFailedWrite" property on the
NamingContextLisener to the value retrieved from the standard context - at this
point in time it's the default value, because the context.xml has not been
processed yet.
3. The context.xml is processed -> OpenEJBContextConfig::contextConfig()
4. The Digester sets that property on the StandardContext instance
5. The NamingContextListener configures the naming context
{code}
namingContext.setExceptionOnFailedWrite(getExceptionOnFailedWrite());
{code}
Where getExceptionOnFailedWrite() returns the value we set in step 2 (i.e. it
returns the default value).
6. As a result the naming context is not configured with the user-provided
configuration in context.xml
---
*Steps to reproduce:*
1. Edit /conf/context.xml and add
jndiExceptionOnFailedWrite='false' attribute to the context element.
{code}
WEB-INF/web.xml
${catalina.base}/conf/web.xml
{code}
2. Execute this simple servlet:
{code}
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/plain");
final PrintWriter writer = resp.getWriter();
try {
final InitialContext ctx = new InitialContext();
final Context compEnv = (Context) ctx.lookup("java:comp/env");
compEnv.close();
writer.println("Closed");
} catch (Exception ex) {
writer.println("Failed to close context: ");
ex.printStackTrace(writer);
}
}
{code}
WebApp is attached for convenience
was:
The TomcatWebAppBuilder does not correctly set the
NamingContextListener.setExceptionOnFailedWrite() property - it always sets the
default value which is "true", instead of the one specified in the context.xml
---
*Execution flow:*
1. TomcatWebAppBuilder:890 creates new NamingContextLisener
2. TomcatWebAppBuilder sets the "exceptionOnFailedWrite" property on the
NamingContextLisener to the value retrieved from the standard context - at this
point in time it's the default value, because the context.xml has not been
processed yet.
3. The context.xml is processed -> OpenEJBContextConfig::contextConfig()
4. The Digester sets that property on the StandardContext instance
5. The NamingContextListener configures the write-ability of the naming context
{code}
namingContext.setExceptionOnFailedWrite(getExceptionOnFailedWrite());
{code}
Where getExceptionOnFailedWrite() returns the value we set in step 2 (i.e. it
returns the default value).
6. As a result the naming context is not configured with the user-provided
configuration in context.xml
---
*Steps to reproduce:*
1. Edit /conf/context.xml and add
jndiExceptionOnFailedWrite='false' attribute to the context element.
{code}
WEB-INF/web.xml
${catalina.base}/conf/web.xml
{code}
2. Execute this simple servlet:
{code}
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/plain");
final PrintWriter writer = resp.getWriter();
try {
final InitialContext ctx = new InitialContext();
final Context compEnv = (Context) ctx.lookup("java:comp/env");
compEnv.close();
writer.println("Closed");
} catch (Exception ex) {
writer.println("Failed to close context: ");
ex.printStackTrace(writer);
}
}
{code}
WebApp is attached for convenience
> TomcatWebAppBuilder does not correctly set
> NamingContextListener.setExceptionOnFailedWrite()
> --
>
> Key: TOMEE-2074
> URL: https://issues.apache.org/jira/browse/TOMEE-2074
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> The TomcatWebAppBuilder does not correctly set the
> NamingContextListener.setExceptionOnFailedWrite() property - it always sets
> the default value which is "true", instead of the one specified in the
> context.xml
> ---
> *Execution flow:*
> 1. TomcatWebAppBuilder:890 creates new NamingContextLisener
> 2. TomcatWebAppBuilder sets the "exceptionOnFailedWrite" property on the
> NamingContextLisener to the value retrieved from the standard context - at
> this point in
[jira] [Updated] (TOMEE-2074) TomcatWebAppBuilder does not correctly set NamingContextListener.setExceptionOnFailedWrite()
[
https://issues.apache.org/jira/browse/TOMEE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2074:
-
Description:
The TomcatWebAppBuilder does not correctly set the
NamingContextListener.setExceptionOnFailedWrite() property - it always sets the
default value which is "true", instead of the one specified in the context.xml
---
*Execution flow:*
1. TomcatWebAppBuilder:890 creates new NamingContextLisener
2. TomcatWebAppBuilder sets the "exceptionOnFailedWrite" property on the
NamingContextLisener to the value retrieved from the standard context - at this
point in time it's the default value, because the context.xml has not been
processed yet.
3. The context.xml is processed -> OpenEJBContextConfig::contextConfig()
4. The Digester sets that property on the StandardContext instance
5. The NamingContextListener configures the write-ability of the naming context
{code}
namingContext.setExceptionOnFailedWrite(getExceptionOnFailedWrite());
{code}
Where getExceptionOnFailedWrite() returns the value we set in step 2 (i.e. it
returns the default value).
6. As a result the naming context is not configured with the user-provided
configuration in context.xml
---
*Steps to reproduce:*
1. Edit /conf/context.xml and add
jndiExceptionOnFailedWrite='false' attribute to the context element.
{code}
WEB-INF/web.xml
${catalina.base}/conf/web.xml
{code}
2. Execute this simple servlet:
{code}
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/plain");
final PrintWriter writer = resp.getWriter();
try {
final InitialContext ctx = new InitialContext();
final Context compEnv = (Context) ctx.lookup("java:comp/env");
compEnv.close();
writer.println("Closed");
} catch (Exception ex) {
writer.println("Failed to close context: ");
ex.printStackTrace(writer);
}
}
{code}
WebApp is attached for convenience
was:
The TomcatWebAppBuilder does not correctly set the
NamingContextListener.setExceptionOnFailedWrite() property - it always sets the
default value which is "true", instead of the one specified in the context.xml
Execution flow:
1. TomcatWebAppBuilder:890 creates new NamingContextLisener
2. TomcatWebAppBuilder sets the "exceptionOnFailedWrite" property on the
NamingContextLisener to the value retrieved from the standard context - at this
point in time it's the default value, because the context.xml has not been
processed yet.
3. The context.xml is processed -> OpenEJBContextConfig::contextConfig()
4. The Digester sets that property on the StandardContext instance
5. The NamingContextListener configures the write-ability of the naming context
{code}
namingContext.setExceptionOnFailedWrite(getExceptionOnFailedWrite());
{code}
Where getExceptionOnFailedWrite() returns the value we set in step 2 (i.e. it
returns the default value).
6. As a result the naming context is not configured with the user-provided
configuration in context.xml
Steps to reproduce:
1. Edit /conf/context.xml and add
jndiExceptionOnFailedWrite='false' attribute to the context element.
{code}
WEB-INF/web.xml
${catalina.base}/conf/web.xml
{code}
2. Execute this simple servlet:
{code}
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/plain");
final PrintWriter writer = resp.getWriter();
try {
final InitialContext ctx = new InitialContext();
final Context compEnv = (Context) ctx.lookup("java:comp/env");
compEnv.close();
writer.println("Closed");
} catch (Exception ex) {
writer.println("Failed to close context: ");
ex.printStackTrace(writer);
}
}
{code}
WebApp is attached for convenience
> TomcatWebAppBuilder does not correctly set
> NamingContextListener.setExceptionOnFailedWrite()
> --
>
> Key: TOMEE-2074
> URL: https://issues.apache.org/jira/browse/TOMEE-2074
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> The TomcatWebAppBuilder does not correctly set the
> NamingContextListener.setExceptionOnFailedWrite() property - it always sets
> the default value which is "true", instead of the one specified in the
> context.xml
> ---
> *Execution flow:*
> 1. TomcatWebAppBuilder:890 creates new NamingContextLisener
> 2. TomcatWebAppBuilder sets the "exceptionOnFailedWrite" property on the
> NamingContextLisener to the value retrieved from the standard context - at
> this
[jira] [Created] (TOMEE-2074) TomcatWebAppBuilder does not correctly set NamingContextListener.setExceptionOnFailedWrite()
Svetlin Zarev created TOMEE-2074:
Summary: TomcatWebAppBuilder does not correctly set
NamingContextListener.setExceptionOnFailedWrite()
Key: TOMEE-2074
URL: https://issues.apache.org/jira/browse/TOMEE-2074
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Attachments: sample.zip
The TomcatWebAppBuilder does not correctly set the
NamingContextListener.setExceptionOnFailedWrite() property - it always sets the
default value which is "true", instead of the one specified in the context.xml
Execution flow:
1. TomcatWebAppBuilder:890 creates new NamingContextLisener
2. TomcatWebAppBuilder sets the "exceptionOnFailedWrite" property on the
NamingContextLisener to the value retrieved from the standard context - at this
point in time it's the default value, because the context.xml has not been
processed yet.
3. The context.xml is processed -> OpenEJBContextConfig::contextConfig()
4. The Digester sets that property on the StandardContext instance
5. The NamingContextListener configures the write-ability of the naming context
{code}
namingContext.setExceptionOnFailedWrite(getExceptionOnFailedWrite());
{code}
Where getExceptionOnFailedWrite() returns the value we set in step 2 (i.e. it
returns the default value).
6. As a result the naming context is not configured with the user-provided
configuration in context.xml
Steps to reproduce:
1. Edit /conf/context.xml and add
jndiExceptionOnFailedWrite='false' attribute to the context element.
{code}
WEB-INF/web.xml
${catalina.base}/conf/web.xml
{code}
2. Execute this simple servlet:
{code}
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/plain");
final PrintWriter writer = resp.getWriter();
try {
final InitialContext ctx = new InitialContext();
final Context compEnv = (Context) ctx.lookup("java:comp/env");
compEnv.close();
writer.println("Closed");
} catch (Exception ex) {
writer.println("Failed to close context: ");
ex.printStackTrace(writer);
}
}
{code}
WebApp is attached for convenience
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TOMEE-2073) In some cases the EJB.beanName() is not processed
[ https://issues.apache.org/jira/browse/TOMEE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059074#comment-16059074 ] Svetlin Zarev commented on TOMEE-2073: -- Added: https://github.com/apache/tomee/pull/76/commits/2d79425f6512a122d7264b1f47388b201c91fb64 > In some cases the EJB.beanName() is not processed > - > > Key: TOMEE-2073 > URL: https://issues.apache.org/jira/browse/TOMEE-2073 > Project: TomEE > Issue Type: Bug >Reporter: Svetlin Zarev > > In some cases the EJB.beanName() is not processed, which results in incorrect > bean resolution. > For instance in the test case from the PR, the ejb-jar descriptor should > complement the information from the EJB annotation. What actually happens is > that the value from the bean name attribute gets ignored, and a wrong bean > gets injected as a result -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TOMEE-2073) In some cases the EJB.beanName() is not processed
[ https://issues.apache.org/jira/browse/TOMEE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058964#comment-16058964 ] Svetlin Zarev commented on TOMEE-2073: -- Sure, I'll try to figure it out after I get back from vacation, if someone does not do it before me :) > In some cases the EJB.beanName() is not processed > - > > Key: TOMEE-2073 > URL: https://issues.apache.org/jira/browse/TOMEE-2073 > Project: TomEE > Issue Type: Bug >Reporter: Svetlin Zarev > > In some cases the EJB.beanName() is not processed, which results in incorrect > bean resolution. > For instance in the test case from the PR, the ejb-jar descriptor should > complement the information from the EJB annotation. What actually happens is > that the value from the bean name attribute gets ignored, and a wrong bean > gets injected as a result -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TOMEE-2073) In some cases the EJB.beanName() is not processed
[ https://issues.apache.org/jira/browse/TOMEE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058943#comment-16058943 ] Svetlin Zarev commented on TOMEE-2073: -- I've decided to go with the arquilian tests. There is very big difference in the behavior of the AppComposer & the arquilian tests. I'm sure it's something that I'm missing, but I'm quite limited on time for this one. > In some cases the EJB.beanName() is not processed > - > > Key: TOMEE-2073 > URL: https://issues.apache.org/jira/browse/TOMEE-2073 > Project: TomEE > Issue Type: Bug >Reporter: Svetlin Zarev > > In some cases the EJB.beanName() is not processed, which results in incorrect > bean resolution. > For instance in the test case from the PR, the ejb-jar descriptor should > complement the information from the EJB annotation. What actually happens is > that the value from the bean name attribute gets ignored, and a wrong bean > gets injected as a result -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TOMEE-2073) In some cases the EJB.beanName() is not processed
Svetlin Zarev created TOMEE-2073: Summary: In some cases the EJB.beanName() is not processed Key: TOMEE-2073 URL: https://issues.apache.org/jira/browse/TOMEE-2073 Project: TomEE Issue Type: Bug Reporter: Svetlin Zarev In some cases the EJB.beanName() is not processed, which results in incorrect bean resolution. For instance in the test case from the PR, the ejb-jar descriptor should complement the information from the EJB annotation. What actually happens is that the value from the bean name attribute gets ignored, and a wrong bean gets injected as a result -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TOMEE-2053) ejb-jar.xml datsources support
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev resolved TOMEE-2053.
--
Resolution: Fixed
Fix Version/s: 7.0.4
> ejb-jar.xml datsources support
> --
>
> Key: TOMEE-2053
> URL: https://issues.apache.org/jira/browse/TOMEE-2053
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Fix For: 7.0.4
>
> Attachments: sample.zip
>
>
> *Test case description:*
> * WAR application with EJB that declares datasource via @DataSourceDefinition
> annotation
> * ejb-jar.xml inside /WEB-INF that overrides the attribute values of the
> bean's annotation.
> *Expectation:*
> The datasource is created with properties specified in the ejb-jar.xml
> *What really happens:*
> The datasource is created with the properties from the annotation and the
> values in the ejb-jar are ignored
> -
> *Sample application & how to test:*
> Attached sample.zip - both sources and WAR. The sample application decaleres
> datasource with annotation with JDBC driver class that does not exists. The
> same application packages ejb-jar.xml that overwrites the faulty JDBC driver
> class with a correct one. If the ejb-jar.xml is taken into account, the app
> should deploy successfully. If the ejb-jar is not taken into account, the app
> will fail to deploy
> *What happens:*
> The sample app fails to deploy because of ClassNotFoundException, because the
> ejb-jar.xml is not taken into account.
> *StackTrace:*
> {code}
> 16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
> collapsed ear in war
> StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
> org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
> class no-such-class
> at
> org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
> at
> org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
> at
> org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
> at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
> at
> org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
> at
> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
> at
> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
> at
> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
> at
> org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
> at
> org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
> at
> org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
> at
> org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
> at
> org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
> at
> org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
> at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
> at
> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
> at
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
>
[jira] [Comment Edited] (TOMEE-2066) Issue with EJB injection
[
https://issues.apache.org/jira/browse/TOMEE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051591#comment-16051591
]
Svetlin Zarev edited comment on TOMEE-2066 at 6/16/17 8:38 AM:
---
The issue was caused by incomplete annotations API (javax.EJB was missing the
lookup() method) on my side.
was (Author: svetlinzarev):
The issue was caused by incomplete javax.annotations API on my side .
> Issue with EJB injection
>
>
> Key: TOMEE-2066
> URL: https://issues.apache.org/jira/browse/TOMEE-2066
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.3
>Reporter: Svetlin Zarev
> Attachments: sample - v2.zip, sample.zip, screenshot-1.png
>
>
> Servlet with:
> {code}
> @EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
> SessionBean firstByBeanName;
> @EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
> SessionBean secondByBeanName;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/first")
> private SessionBean firstByLookup;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/second")
> private SessionBean secondByLookup;
> {code}
> Expected Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.FirstBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Actual Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.SecondBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Problem:
> "FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
> same instance - i.e. either FirstBean or SecondBean, while FirstBean should
> be injected FisrtBean, and SecondBean -> SecondBean.
> Attached application that reproduces the issue and prints the naming context
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2066) Issue with EJB injection
[
https://issues.apache.org/jira/browse/TOMEE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2066:
-
Attachment: sample - v2.zip
> Issue with EJB injection
>
>
> Key: TOMEE-2066
> URL: https://issues.apache.org/jira/browse/TOMEE-2066
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.3
>Reporter: Svetlin Zarev
> Attachments: sample - v2.zip, sample.zip
>
>
> Servlet with:
> {code}
> @EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
> SessionBean firstByBeanName;
> @EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
> SessionBean secondByBeanName;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/first")
> private SessionBean firstByLookup;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/second")
> private SessionBean secondByLookup;
> {code}
> Expected Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.FirstBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Actual Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.SecondBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Problem:
> "FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
> same instance - i.e. either FirstBean or SecondBean, while FirstBean should
> be injected FisrtBean, and SecondBean -> SecondBean.
> Attached application that reproduces the issue and prints the naming context
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2066) Issue with EJB injection
[
https://issues.apache.org/jira/browse/TOMEE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2066:
-
Affects Version/s: 7.0.3
> Issue with EJB injection
>
>
> Key: TOMEE-2066
> URL: https://issues.apache.org/jira/browse/TOMEE-2066
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.3
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> Servlet with:
> {code}
> @EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
> SessionBean firstByBeanName;
> @EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
> SessionBean secondByBeanName;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/first")
> private SessionBean firstByLookup;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/second")
> private SessionBean secondByLookup;
> {code}
> Expected Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.FirstBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Actual Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.SecondBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Problem:
> "FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
> same instance - i.e. either FirstBean or SecondBean, while FirstBean should
> be injected FisrtBean, and SecondBean -> SecondBean.
> Attached application that reproduces the issue and prints the naming context
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TOMEE-2066) Issue with EJB injection
[
https://issues.apache.org/jira/browse/TOMEE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050383#comment-16050383
]
Svetlin Zarev commented on TOMEE-2066:
--
Shouldn't the first annotation bind FirstBean to
"java:comp/env/ejb/TestServlet/first"
{code}
@EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
SessionBean firstByBeanName;
{code}
When I print the context from the servlet, I can see that such reference exists:
{code}
### Context: /comp/env/ejb/TestServlet
Name: first Class=org.apache.openejb.core.ivm.naming.IntraVmJndiReference
[Reference]: proxy=org.example.SessionBean;deployment=ROOT//FirstBean;pk=null
{code}
My expectation is that the second annotation will look up the bean using that
reference:
{code}
@EJB(lookup = "java:comp/env/ejb/TestServlet/first")
private SessionBean firstByLookup;
{code}
For instance lookup from servlet using InitialContext works as expected.
PS: That case works on glassfish / wildfly / TomEE 1.7
> Issue with EJB injection
>
>
> Key: TOMEE-2066
> URL: https://issues.apache.org/jira/browse/TOMEE-2066
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> Servlet with:
> {code}
> @EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
> SessionBean firstByBeanName;
> @EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
> SessionBean secondByBeanName;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/first")
> private SessionBean firstByLookup;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/second")
> private SessionBean secondByLookup;
> {code}
> Expected Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.FirstBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Actual Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.SecondBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Problem:
> "FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
> same instance - i.e. either FirstBean or SecondBean, while FirstBean should
> be injected FisrtBean, and SecondBean -> SecondBean.
> Attached application that reproduces the issue and prints the naming context
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2066) Issue with EJB injection
[
https://issues.apache.org/jira/browse/TOMEE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2066:
-
Description:
Servlet with:
{code}
@EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
SessionBean firstByBeanName;
@EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
SessionBean secondByBeanName;
@EJB(lookup = "java:comp/env/ejb/TestServlet/first")
private SessionBean firstByLookup;
@EJB(lookup = "java:comp/env/ejb/TestServlet/second")
private SessionBean secondByLookup;
{code}
Expected Output:
{code}
FirstBean (by BeanName): org.example.FirstBean
SecondBean (by BeanName): org.example.SecondBean
FirstBean (by lookup): org.example.FirstBean
SecondBean (by lookup): org.example.SecondBean
{code}
Actual Output:
{code}
FirstBean (by BeanName): org.example.FirstBean
SecondBean (by BeanName): org.example.SecondBean
FirstBean (by lookup): org.example.SecondBean
SecondBean (by lookup): org.example.SecondBean
{code}
Problem:
"FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
same instance - i.e. either FirstBean or SecondBean, while FirstBean should be
injected FisrtBean, and SecondBean -> SecondBean.
Attached application that reproduces the issue and prints the naming context
was:
*Test case: *
Servlet with:
{code}
@EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
SessionBean firstByBeanName;
@EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
SessionBean secondByBeanName;
@EJB(lookup = "java:comp/env/ejb/TestServlet/first")
private SessionBean firstByLookup;
@EJB(lookup = "java:comp/env/ejb/TestServlet/second")
private SessionBean secondByLookup;
{code}
Expected Output:
{code}
FirstBean (by BeanName): org.example.FirstBean
SecondBean (by BeanName): org.example.SecondBean
FirstBean (by lookup): org.example.FirstBean
SecondBean (by lookup): org.example.SecondBean
{code}
Actual Output:
{code}
FirstBean (by BeanName): org.example.FirstBean
SecondBean (by BeanName): org.example.SecondBean
FirstBean (by lookup): org.example.SecondBean
SecondBean (by lookup): org.example.SecondBean
{code}
Problem:
"FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
same instance - i.e. either FirstBean or SecondBean, while FirstBean should be
injected FisrtBean, and SecondBean -> SecondBean.
Attached application that reproduces the issue and prints the naming context
> Issue with EJB injection
>
>
> Key: TOMEE-2066
> URL: https://issues.apache.org/jira/browse/TOMEE-2066
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> Servlet with:
> {code}
> @EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
> SessionBean firstByBeanName;
> @EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
> SessionBean secondByBeanName;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/first")
> private SessionBean firstByLookup;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/second")
> private SessionBean secondByLookup;
> {code}
> Expected Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.FirstBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Actual Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.SecondBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Problem:
> "FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
> same instance - i.e. either FirstBean or SecondBean, while FirstBean should
> be injected FisrtBean, and SecondBean -> SecondBean.
> Attached application that reproduces the issue and prints the naming context
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2066) Issue with EJB injection
[
https://issues.apache.org/jira/browse/TOMEE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2066:
-
Summary: Issue with EJB injection (was: Issue with EJB inection)
> Issue with EJB injection
>
>
> Key: TOMEE-2066
> URL: https://issues.apache.org/jira/browse/TOMEE-2066
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> *Test case: *
> Servlet with:
> {code}
> @EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
> SessionBean firstByBeanName;
> @EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
> SessionBean secondByBeanName;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/first")
> private SessionBean firstByLookup;
> @EJB(lookup = "java:comp/env/ejb/TestServlet/second")
> private SessionBean secondByLookup;
> {code}
> Expected Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.FirstBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Actual Output:
> {code}
> FirstBean (by BeanName): org.example.FirstBean
> SecondBean (by BeanName): org.example.SecondBean
> FirstBean (by lookup): org.example.SecondBean
> SecondBean (by lookup): org.example.SecondBean
> {code}
> Problem:
> "FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
> same instance - i.e. either FirstBean or SecondBean, while FirstBean should
> be injected FisrtBean, and SecondBean -> SecondBean.
> Attached application that reproduces the issue and prints the naming context
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2066) Issue with EJB inection
Svetlin Zarev created TOMEE-2066:
Summary: Issue with EJB inection
Key: TOMEE-2066
URL: https://issues.apache.org/jira/browse/TOMEE-2066
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Attachments: sample.zip
*Test case: *
Servlet with:
{code}
@EJB(beanName = "FirstBean", name = "ejb/TestServlet/first")
SessionBean firstByBeanName;
@EJB(beanName = "SecondBean", name = "ejb/TestServlet/second")
SessionBean secondByBeanName;
@EJB(lookup = "java:comp/env/ejb/TestServlet/first")
private SessionBean firstByLookup;
@EJB(lookup = "java:comp/env/ejb/TestServlet/second")
private SessionBean secondByLookup;
{code}
Expected Output:
{code}
FirstBean (by BeanName): org.example.FirstBean
SecondBean (by BeanName): org.example.SecondBean
FirstBean (by lookup): org.example.FirstBean
SecondBean (by lookup): org.example.SecondBean
{code}
Actual Output:
{code}
FirstBean (by BeanName): org.example.FirstBean
SecondBean (by BeanName): org.example.SecondBean
FirstBean (by lookup): org.example.SecondBean
SecondBean (by lookup): org.example.SecondBean
{code}
Problem:
"FirstBean (by lookup)" or "SecondBean (by lookup)" are always injected the
same instance - i.e. either FirstBean or SecondBean, while FirstBean should be
injected FisrtBean, and SecondBean -> SecondBean.
Attached application that reproduces the issue and prints the naming context
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2064) NPE in CdiEjbBean.java:532
[
https://issues.apache.org/jira/browse/TOMEE-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2064:
-
Attachment: npe-1.zip
Hi,
I'm attaching a reproducible example.
Kind regards,
Svetlin
> NPE in CdiEjbBean.java:532
> --
>
> Key: TOMEE-2064
> URL: https://issues.apache.org/jira/browse/TOMEE-2064
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: npe-1.zip
>
>
> TomEE 7.0.4 "master" started throwing NPE in CdiEjbBean.java:532
> {code}
> java.lang.NullPointerException: while trying to get the length of a null
> array loaded from a local variable at slot 6
> at
> org.apache.openejb.cdi.CdiEjbBean$EjbInjectionTargetImpl.createNewPojo(CdiEjbBean.java:532)
> at org.apache.openejb.BeanContext.newInstance(BeanContext.java:1608)
> at
> org.apache.openejb.core.stateless.StatelessInstanceManager.createInstance(StatelessInstanceManager.java:242)
> at
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:234)
> at
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:204)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
> at
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:347)
> {code}
> I've fixed it by simple check for null and it fixed my tests. What do you
> think ?
> https://github.com/apache/tomee/compare/master...SvetlinZarev:fixNpe?expand=1
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2064) NPE in CdiEjbBean.java:532
Svetlin Zarev created TOMEE-2064:
Summary: NPE in CdiEjbBean.java:532
Key: TOMEE-2064
URL: https://issues.apache.org/jira/browse/TOMEE-2064
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
TomEE 7.0.4 "master" started throwing NPE in CdiEjbBean.java:532
{code}
java.lang.NullPointerException: while trying to get the length of a null array
loaded from a local variable at slot 6
at
org.apache.openejb.cdi.CdiEjbBean$EjbInjectionTargetImpl.createNewPojo(CdiEjbBean.java:532)
at org.apache.openejb.BeanContext.newInstance(BeanContext.java:1608)
at
org.apache.openejb.core.stateless.StatelessInstanceManager.createInstance(StatelessInstanceManager.java:242)
at
org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:234)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:204)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:265)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:260)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:89)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:347)
{code}
I've fixed it by simple check for null and it fixed my tests. What do you think
?
https://github.com/apache/tomee/compare/master...SvetlinZarev:fixNpe?expand=1
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TOMEE-1934) Incorrect double-check locking
[
https://issues.apache.org/jira/browse/TOMEE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047725#comment-16047725
]
Svetlin Zarev commented on TOMEE-1934:
--
It was discovered by a Fortify scan, but it can be false positive (if it's
running in a single thread)
> Incorrect double-check locking
> --
>
> Key: TOMEE-1934
> URL: https://issues.apache.org/jira/browse/TOMEE-1934
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>Priority: Trivial
>
> http://www.cs.umd.edu/%7Epugh/java/memoryModel/DoubleCheckedLocking.html
> {code}
> public BeanManagerImpl getBeanManagerImpl() {
> if (bm == null) { // should be done in the constructor
> synchronized (this) {
> if (bm == null) {
> bm = new WebappBeanManager(this);
> }
> }
> }
> return bm;
> }
> {code}
> Unless **bm** is volatile, multiple instances of the bean manager can be
> created under concurrent conditions.
> PS: I saw the suppress warning. I'm not sure if PMD just warns against DCL or
> that it was broken.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2062) HSQLDB Deadlock
[
https://issues.apache.org/jira/browse/TOMEE-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2062:
-
Issue Type: Improvement (was: Bug)
> HSQLDB Deadlock
> ---
>
> Key: TOMEE-2062
> URL: https://issues.apache.org/jira/browse/TOMEE-2062
> Project: TomEE
> Issue Type: Improvement
>Reporter: Svetlin Zarev
>Priority: Minor
>
> I was running tests with eclipselink on my vanilla tomee when it just froze
> during one of the tests. After a little bit of debugging and research it
> turned out to be a well known issue with HSQLDB: [1]
> {code}
> The default transaction model is LOCKS which locks a table that is modified
> until the transaction is committed. You can use the MVCC model instead, which
> allows other sessions to read from the table and to modify rows that have not
> been modified.
> {code}
> The solution as stated in the SO answer is to add ;hsqldb.tx=mvcc to the
> hsqldb connection string. IMO it would make sense add this to the default
> connection string specified in tomee-webapp's service-jar.xml, so it becomes:
> {code}
> parent="org.apache.openejb:Default JDBC Database">
> JdbcUrl=jdbc:hsqldb:file:data/hsqldb/hsqldb;hsqldb.tx=mvcc
>
>parent="org.apache.openejb:Default Unmanaged JDBC Database">
> JdbcUrl=jdbc:hsqldb:file:data/hsqldb/hsqldb;hsqldb.tx=mvcc
>
> {code}
> [1] https://stackoverflow.com/a/16109062/2588800
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2062) HSQLDB Deadlock
[
https://issues.apache.org/jira/browse/TOMEE-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2062:
-
Priority: Minor (was: Major)
> HSQLDB Deadlock
> ---
>
> Key: TOMEE-2062
> URL: https://issues.apache.org/jira/browse/TOMEE-2062
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>Priority: Minor
>
> I was running tests with eclipselink on my vanilla tomee when it just froze
> during one of the tests. After a little bit of debugging and research it
> turned out to be a well known issue with HSQLDB: [1]
> {code}
> The default transaction model is LOCKS which locks a table that is modified
> until the transaction is committed. You can use the MVCC model instead, which
> allows other sessions to read from the table and to modify rows that have not
> been modified.
> {code}
> The solution as stated in the SO answer is to add ;hsqldb.tx=mvcc to the
> hsqldb connection string. IMO it would make sense add this to the default
> connection string specified in tomee-webapp's service-jar.xml, so it becomes:
> {code}
> parent="org.apache.openejb:Default JDBC Database">
> JdbcUrl=jdbc:hsqldb:file:data/hsqldb/hsqldb;hsqldb.tx=mvcc
>
>parent="org.apache.openejb:Default Unmanaged JDBC Database">
> JdbcUrl=jdbc:hsqldb:file:data/hsqldb/hsqldb;hsqldb.tx=mvcc
>
> {code}
> [1] https://stackoverflow.com/a/16109062/2588800
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2062) HSQLDB Deadlock
Svetlin Zarev created TOMEE-2062:
Summary: HSQLDB Deadlock
Key: TOMEE-2062
URL: https://issues.apache.org/jira/browse/TOMEE-2062
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
I was running tests with eclipselink on my vanilla tomee when it just froze
during one of the tests. After a little bit of debugging and research it turned
out to be a well known issue with HSQLDB: [1]
{code}
The default transaction model is LOCKS which locks a table that is modified
until the transaction is committed. You can use the MVCC model instead, which
allows other sessions to read from the table and to modify rows that have not
been modified.
{code}
The solution as stated in the SO answer is to add ;hsqldb.tx=mvcc to the hsqldb
connection string. IMO it would make sense add this to the default connection
string specified in tomee-webapp's service-jar.xml, so it becomes:
{code}
JdbcUrl=jdbc:hsqldb:file:data/hsqldb/hsqldb;hsqldb.tx=mvcc
JdbcUrl=jdbc:hsqldb:file:data/hsqldb/hsqldb;hsqldb.tx=mvcc
{code}
[1] https://stackoverflow.com/a/16109062/2588800
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044365#comment-16044365
]
Svetlin Zarev edited comment on TOMEE-2057 at 6/9/17 12:27 PM:
---
I've moved eclipselink's JTASynchronizationListener with the debugger after
openejb's SessionSynchronizationCoordinator for the duration of the request and
this seems to have fixed my issue.
But I'm not sure how can I really fix it, because
SessionSynchronizationCoordinator is being registered in the interposed sync
list, while JTASynchronizationListener is being registered in the "regular"
sync list. The issue is that the interposed list is always executed after the
regular list. In other words @BeforeCompletion is executed always after
eclipselink commits its unit of work.
---
I've modified the JtaTransactionPolicy to register the
SessionSynchronizationCoordinator on the regular sync list instead of the
interposed, thus it will be executed before the JTASynchronizationListener .
[~romain.manni-bucau] What do you think ?
was (Author: svetlinzarev):
I've moved eclipselink's JTASynchronizationListener with the debugger after
openejb's SessionSynchronizationCoordinator for the duration of the request and
this seems to have fixed my issue.
But I'm not sure how can I really fix it, because
SessionSynchronizationCoordinator is being registered in the interposed sync
list, while JTASynchronizationListener is being registered in the "regular"
sync list. The issue is that the interposed list is always executed after the
regular list. In other words @BeforeCompletion is executed always after
eclipselink commits its unit of work.
---
I've modified the JtaTransactionPolicy to register the
SessionSynchronizationCoordinator on the regular sync list instead of the
interposed, thus it will be executed before the JTASynchronizationListener .
What do you think ?
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Attachments: sample-v2.zip, sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = ;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
> throw new IllegalStateException("Entity not persisted in
> TX_REQUIRED");
> }
> }
> }
> {code}
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044365#comment-16044365
]
Svetlin Zarev commented on TOMEE-2057:
--
I've moved eclipselink's JTASynchronizationListener with the debugger after
openejb's SessionSynchronizationCoordinator for the duration of the request and
this seems to have fixed my issue.
But I'm not sure how can I really fix it, because
SessionSynchronizationCoordinator is being registered in the interposed sync
list, while JTASynchronizationListener is being registered in the "regular"
sync list. The issue is that the interposed list is always executed after the
regular list. In other words @BeforeCompletion is executed always after
eclipselink commits its unit of work.
---
I've modified the JtaTransactionPolicy to register the
SessionSynchronizationCoordinator on the regular sync list instead of the
interposed, thus it will be executed before the JTASynchronizationListener .
What do you think ?
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Attachments: sample-v2.zip, sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = ;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
> throw new IllegalStateException("Entity not persisted in
> TX_REQUIRED");
> }
> }
> }
> {code}
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044330#comment-16044330
]
Svetlin Zarev edited comment on TOMEE-2057 at 6/9/17 11:33 AM:
---
You are right elipselink's synchronization was invoked before
SessionSynchronizationCoordinator which in turn invokes @BeforeCompletion.
was (Author: svetlinzarev):
You are right elipselink's synchronization was invoked before
SessionSynchronizationCoordinator which in turn invokes @AfterCompletion.
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Attachments: sample-v2.zip, sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = ;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
> throw new IllegalStateException("Entity not persisted in
> TX_REQUIRED");
> }
> }
> }
> {code}
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044330#comment-16044330
]
Svetlin Zarev commented on TOMEE-2057:
--
You are right elipselink's synchronization was invoked before
SessionSynchronizationCoordinator which in turn invokes @AfterCompletion.
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Attachments: sample-v2.zip, sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = ;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
> throw new IllegalStateException("Entity not persisted in
> TX_REQUIRED");
> }
> }
> }
> {code}
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2057:
-
Attachment: sample-v2.zip
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Attachments: sample-v2.zip, sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = ;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
> throw new IllegalStateException("Entity not persisted in
> TX_REQUIRED");
> }
> }
> }
> {code}
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2057:
-
Description:
I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
defined. It tries to persist a JPA entity in each one of them:
{code}
@Stateful
public class SessionBean implements Serializable {
public static final int ID_AFTER_BEGIN = 1234;
public static final int ID_BEFORE_COMPLETION = 5678;
public static final int ID_TX_ENTITY = ;
@PersistenceContext
EntityManager em;
@AfterBegin
public void afterBegin() {
final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
AFTER_BEGIN");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
throw new IllegalStateException("Entity not persisted in
AFTER_BEGIN");
}
}
@BeforeCompletion
public void beforeCompletion() {
final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
BEFORE_COMPLETION");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
throw new IllegalStateException("Entity not persisted in
BEFORE_COMPLETION");
}
}
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void txRequired() {
final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
TX_REQUIRED");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
throw new IllegalStateException("Entity not persisted in
TX_REQUIRED");
}
}
}
{code}
During the transaction everything seems fine, but after the transaction
EntityManger.find() returns null for the bean persisted during @BeforeCompletion
I've attached sample app that reproduces the issue.
*Expected result:*
The output does not contain any failed tests.
*Actual result:*
{code}
TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
{code}
PS: I observe a similar issue for @AfterBegin in another case, but I'm not able
to extract a reproducible test case from it. But I thinkthe two issues are
linked
was:
I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
defined. It tries to persist a JPA entity in each one of them:
{code}
@Stateful
public class SessionBean implements Serializable {
public static final int ID_AFTER_BEGIN = 1234;
public static final int ID_BEFORE_COMPLETION = 5678;
public static final int ID_TX_ENTITY = ;
@PersistenceContext
EntityManager em;
@AfterBegin
public void afterBegin() {
final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
AFTER_BEGIN");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
throw new IllegalStateException("Entity not persisted in
AFTER_BEGIN");
}
}
@BeforeCompletion
public void beforeCompletion() {
final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
BEFORE_COMPLETION");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
throw new IllegalStateException("Entity not persisted in
BEFORE_COMPLETION");
}
}
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void txRequired() {
final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
TX_REQUIRED");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
throw new IllegalStateException("Entity not persisted in
TX_REQUIRED");
}
}
}
{code}
During the transaction everything seems fine, but after the transaction
EntityManger.find() returns null for the bean persisted during @BeforeCompletion
I've attached sample app that reproduces the issue.
*Expected result:*
The output does not contain any failed tests.
*Actual result:*
{code}
TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
TESTING TX_REQUIRED WITH EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
{code}
PS: I observe a similar issue for @AfterBegin in another case, but I'm not able
to extract a reproducible test case from it. But I thinkthe two issues are
linked
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public
[jira] [Updated] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2057:
-
Component/s: TomEE Core Server
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = ;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
> throw new IllegalStateException("Entity not persisted in
> TX_REQUIRED");
> }
> }
> }
> {code}
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> TESTING TX_REQUIRED WITH EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2057:
-
Description:
I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
defined. It tries to persist a JPA entity in each one of them:
{code}
@Stateful
public class SessionBean implements Serializable {
public static final int ID_AFTER_BEGIN = 1234;
public static final int ID_BEFORE_COMPLETION = 5678;
public static final int ID_TX_ENTITY = ;
@PersistenceContext
EntityManager em;
@AfterBegin
public void afterBegin() {
final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
AFTER_BEGIN");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
throw new IllegalStateException("Entity not persisted in
AFTER_BEGIN");
}
}
@BeforeCompletion
public void beforeCompletion() {
final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
BEFORE_COMPLETION");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
throw new IllegalStateException("Entity not persisted in
BEFORE_COMPLETION");
}
}
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void txRequired() {
final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
TX_REQUIRED");
em.persist(entity);
if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
throw new IllegalStateException("Entity not persisted in
TX_REQUIRED");
}
}
}
{code}
During the transaction everything seems fine, but after the transaction
EntityManger.find() returns null for the bean persisted during @BeforeCompletion
I've attached sample app that reproduces the issue.
*Expected result:*
The output does not contain any failed tests.
*Actual result:*
{code}
TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
TESTING TX_REQUIRED WITH EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
{code}
PS: I observe a similar issue for @AfterBegin in another case, but I'm not able
to extract a reproducible test case from it. But I thinkthe two issues are
linked
was:
I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
defined. It tries to persist a JPA entity in each one of them.
During the transaction everything seems fine, but after the transaction
EntityManger.find() returns null for the bean persisted during @BeforeCompletion
I've attached sample app that reproduces the issue.
*Expected result:*
The output does not contain any failed tests.
*Actual result:*
{code}
TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
TESTING TX_REQUIRED WITH EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
{code}
PS: I observe a similar issue for @AfterBegin in another case, but I'm not able
to extract a reproducible test case from it. But I thinkthe two issues are
linked
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = ;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
>
[jira] [Updated] (TOMEE-2057) @BeforeCompletion callback issue
[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2057:
-
Description:
I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
defined. It tries to persist a JPA entity in each one of them.
During the transaction everything seems fine, but after the transaction
EntityManger.find() returns null for the bean persisted during @BeforeCompletion
I've attached sample app that reproduces the issue.
*Expected result:*
The output does not contain any failed tests.
*Actual result:*
{code}
TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
TESTING TX_REQUIRED WITH EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
{code}
PS: I observe a similar issue for @AfterBegin in another case, but I'm not able
to extract a reproducible test case from it. But I thinkthe two issues are
linked
was:
I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
defined. It tries to persist a JPA entity in each one of them.
Dureing the transaction everithing seems fine, but after the transaction, the
EntityManger.find() returns null for the bean persisted during @BeforeCompletion
I've attached sample app that reproduces the issue.
*Expected result:*
The output does not contain any failed tests.
*Actual result:*
{code}
TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
TESTING TX_REQUIRED WITH EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
{code}
> @BeforeCompletion callback issue
> -
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them.
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> TESTING TX_REQUIRED WITH EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TOMEE-2057) @BeforeCompletion callback issue
Svetlin Zarev created TOMEE-2057:
Summary: @BeforeCompletion callback issue
Key: TOMEE-2057
URL: https://issues.apache.org/jira/browse/TOMEE-2057
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Attachments: sample.zip
I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
defined. It tries to persist a JPA entity in each one of them.
Dureing the transaction everithing seems fine, but after the transaction, the
EntityManger.find() returns null for the bean persisted during @BeforeCompletion
I've attached sample app that reproduces the issue.
*Expected result:*
The output does not contain any failed tests.
*Actual result:*
{code}
TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
TESTING TX_REQUIRED WITH EXISTING TRANSACTION
[TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2053) ejb-jar.xml datsources support
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2053:
-
Description:
*Test case description:*
* WAR application with EJB that declares datasource via @DataSourceDefinition
annotation
* ejb-jar.xml inside /WEB-INF that overrides the attribute values of the bean's
annotation.
*Expectation:*
The datasource is created with properties specified in the ejb-jar.xml
*What really happens:*
The datasource is created with the properties from the annotation and the
values in the ejb-jar are ignored
-
*Sample application & how to test:*
Attached sample.zip - both sources and WAR. The sample application decaleres
datasource with annotation with JDBC driver class that does not exists. The
same application packages ejb-jar.xml that overwrites the faulty JDBC driver
class with a correct one. If the ejb-jar.xml is taken into account, the app
should deploy successfully. If the ejb-jar is not taken into account, the app
will fail to deploy
*What happens:*
The sample app fails to deploy because of ClassNotFoundException, because the
ejb-jar.xml is not taken into account.
*StackTrace:*
{code}
16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
class no-such-class
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
at
org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
at
org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
at
org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
at
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at
org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:807)
Caused by: java.lang.ClassNotFoundException: no-such-class
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:204)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Native Method)
at
[jira] [Updated] (TOMEE-2053) ejb-jar.xml should take precedence over annotations
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2053:
-
Component/s: TomEE Core Server
> ejb-jar.xml should take precedence over annotations
> ---
>
> Key: TOMEE-2053
> URL: https://issues.apache.org/jira/browse/TOMEE-2053
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> *Test case description:*
> * WAR application with EJB that declares datasource via @DataSourceDefinition
> annotation
> * ejb-jar.xml inside /WEB-INF that overrides the attribute values.
> *Expectation:*
> The datasource is created with properties specified in the ejb-jar.xml
> *What really happens:*
> The datasource is created with the properties from the annotation and the
> values in the ejb-jar are ignored
> -
> *Sample application & how to test:*
> Attached sample.zip - both sources and WAR. The sample application decaleres
> datasource with annotation with JDBC driver class that does not exists. The
> same application packages ejb-jar.xml that overwrites the faulty JDBC driver
> class with a correct one. If the ejb-jar.xml is taken into account, the app
> should deploy successfully. If the ejb-jar is not taken into account, the app
> will fail to deploy
> *What happens:*
> The sample app fails to deploy because of ClassNotFoundException, because the
> ejb-jar.xml is not taken into account.
> *StackTrace:*
> {code}
> 16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
> collapsed ear in war
> StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
> org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
> class no-such-class
> at
> org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
> at
> org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
> at
> org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
> at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
> at
> org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
> at
> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
> at
> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
> at
> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
> at
> org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
> at
> org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
> at
> org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
> at
> org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
> at
> org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
> at
> org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
> at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
> at
> org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
> at
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
>
[jira] [Updated] (TOMEE-2053) ejb-jar.xml should take precedence over annotations
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2053:
-
Description:
*Test case description:*
* WAR application with EJB that declares datasource via @DataSourceDefinition
annotation
* ejb-jar.xml inside /WEB-INF that overrides the attribute values.
*Expectation:*
The datasource is created with properties specified in the ejb-jar.xml
*What really happens:*
The datasource is created with the properties from the annotation and the
values in the ejb-jar are ignored
-
*Sample application & how to test:*
Attached sample.zip - both sources and WAR. The sample application decaleres
datasource with annotation with JDBC driver class that does not exists. The
same application packages ejb-jar.xml that overwrites the faulty JDBC driver
class with a correct one. If the ejb-jar.xml is taken into account, the app
should deploy successfully. If the ejb-jar is not taken into account, the app
will fail to deploy
*What happens:*
The sample app fails to deploy because of ClassNotFoundException, because the
ejb-jar.xml is not taken into account.
*StackTrace:*
{code}
16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
class no-such-class
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
at
org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
at
org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
at
org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
at
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at
org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:807)
Caused by: java.lang.ClassNotFoundException: no-such-class
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:204)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forNameFW(Class.java:288)
at
[jira] [Updated] (TOMEE-2053) ejb-jar.xml should take precedence over annotations
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2053:
-
Description:
*Test case description:*
* WAR application with EJB that declares datasource via @DataSourceDefinition
annotation
* ejb-jar.xml inside /WEB-INF that overrides the attribute values.
*Expectation:*
The datasource is created with properties specified in the ejb-jar.xml
*What really happens:*
The datasource is created with the properties from the annotation and the
values in the ejb-jar are ignored
-
*Sample application & how to test:*
Attached sample.zip - both sources and WAR. The sample application decaleres
datasource with annotation with JDBC driver class that does not exists. The
same application packages ejb-jar.xml that overwrites the faulty JDBC driver
class with a correct one.
*What happens:*
The sample app fails to deploy because of ClassNotFoundException, because the
ejb-jar.xml is not taken into account.
*StackTrace:*
{code}
16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
class no-such-class
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
at
org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
at
org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
at
org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
at
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at
org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:807)
Caused by: java.lang.ClassNotFoundException: no-such-class
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:204)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forNameFW(Class.java:288)
at java.lang.Class.forName(Class.java:281)
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:40)
... 32 common frames
[jira] [Updated] (TOMEE-2053) ejb-jar.xml should take precedence over annotations
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2053:
-
Description:
*Test case description:*
* WAR application with EJB that declares datasource via @DataSourceDefinition
annotation
* ejb-jar.xml inside /WEB-INF that overrides the attribute values.
*Expectation:*
The datasource is created with properties specified in the ejb-jar.xml
*What really happens:*
The datasource is created with the properties from the annotation and the
values in the ejb-jar are ignored
-
*Sample application & how to test:*
Attached sample.zip - both sources and WAR. The sample application decaleres
datasource with annotation with JDBC driver class that does not exists. The
same application packages ejb-jar.xml that overwrites the faulty JDBC driver
class with a correct one.
*What happens: *
The sample app fails to deploy because of ClassNotFoundException, because the
ejb-jar.xml is not taken into account.
*StackTrace:*
{code}
16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
class no-such-class
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
at
org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
at
org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
at
org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
at
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at
org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:807)
Caused by: java.lang.ClassNotFoundException: no-such-class
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:204)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forNameFW(Class.java:288)
at java.lang.Class.forName(Class.java:281)
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:40)
... 32 common frames
[jira] [Updated] (TOMEE-2053) ejb-jar.xml should take precedence over annotations
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2053:
-
Description:
*Test case description:*
* WAR application with EJB that declares datasource via @DataSourceDefinition
annotation
* ejb-jar.xml inside /WEB-INF that overrides the attribute values.
*Expectation:*
The datasource is created with properties specified in the ejb-jar.xml
*What really happens:*
The datasource is created with the properties from the annotation
-
*Sample application & how to test:*
Attached sample.zip - both sources and WAR. The sample application decaleres
datasource with annotation with JDBC driver class that does not exists. The
same application packages ejb-jar.xml that overwrites the faulty JDBC driver
class with a correct one.
*What happens: *
The sample app fails to deploy because of ClassNotFoundException, because the
ejb-jar.xml is not taken into account.
*StackTrace:*
{code}
16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
class no-such-class
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
at
org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
at
org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
at
org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
at
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at
org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:807)
Caused by: java.lang.ClassNotFoundException: no-such-class
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:204)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forNameFW(Class.java:288)
at java.lang.Class.forName(Class.java:281)
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:40)
... 32 common frames omitted
{code}
was:
*Test case
[jira] [Updated] (TOMEE-2053) ejb-jar.xml should take precedence over annotations
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2053:
-
Description:
*Test case description:*
* WAR application with EJB that declares datasource via @DataSourceDefinition
annotation
* ejb-jar.xml inside /WEB-INF that overrides the attribute values.
*Expectation:*
The datasource is created with properties specified in the ejb-jar.xml
*What really happens:*
The datasource is created with the properties from the annotation
---
*Sample application & how to test:*
Attached sample.zip - both sources and WAR. The sample application decaleres
datasource with annotation with JDBC driver class that does not exists. The
same application packages ejb-jar.xml that overwrites the faulty JDBC driver
class with a correct one.
*What happens: *
The sample app fails to deploy because of ClassNotFoundException, because the
ejb-jar.xml is not taken into account.
*StackTrace:*
{code}
16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
class no-such-class
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
at
org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
at
org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
at
org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
at
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at
org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:807)
Caused by: java.lang.ClassNotFoundException: no-such-class
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:204)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forNameFW(Class.java:288)
at java.lang.Class.forName(Class.java:281)
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:40)
... 32 common frames omitted
{code}
was:
*Test case description:*
* WAR application with EJB that declares
[jira] [Updated] (TOMEE-2053) ejb-jar.xml should take precedence over annotations
[
https://issues.apache.org/jira/browse/TOMEE-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2053:
-
Description:
*Test case description:*
* WAR application with EJB that declares datasource via @DataSourceDefinition
annotation
* ejb-jar.xml inside /WEB-INF that overrides the attribute values.
*Expectation:*
The datasource is created with properties specified in the ejb-jar.xml
*What really happens:*
The datasource is created with the properties from the annotation
*Sample application & how to test:*
Attached sample.zip - both sources and WAR. The sample application decaleres
datasource with annotation with JDBC driver class that does not exists. The
same application packages ejb-jar.xml that overwrites the faulty JDBC driver
class with a correct one.
*What happens: *
The sample app fails to deploy because of ClassNotFoundException, because the
ejb-jar.xml is not taken into account.
*StackTrace:*
{code}
16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
class no-such-class
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
at
org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
at
org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
at
org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
at
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at
org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:807)
Caused by: java.lang.ClassNotFoundException: no-such-class
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:204)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forNameFW(Class.java:288)
at java.lang.Class.forName(Class.java:281)
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:40)
... 32 common frames omitted
{code}
was:
Test case description:
* WAR application with EJB that declares datasource
[jira] [Created] (TOMEE-2053) ejb-jar.xml should take precedence over annotations
Svetlin Zarev created TOMEE-2053:
Summary: ejb-jar.xml should take precedence over annotations
Key: TOMEE-2053
URL: https://issues.apache.org/jira/browse/TOMEE-2053
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Attachments: sample.zip
Test case description:
* WAR application with EJB that declares datasource via @DataSourceDefinition
annotation
* ejb-jar.xml inside /WEB-INF that overrides the attribute values.
Expectation:
The datasource is created with properties specified in the ejb-jar.xml
What really happens:
The datasource is created with the properties from the annotation
Sample application & how to test:
Attached sample.zip - both sources and WAR. The sample application decaleres
datasource with annotation with JDBC driver class that does not exists. The
same application packages ejb-jar.xml that overwrites the faulty JDBC driver
class with a correct one.
What happens:
The sample app fails to deploy because of ClassNotFoundException, because the
ejb-jar.xml is not taken into account.
StackTrace:
{code}
16:08:39.221 [localhost-startStop-1] ERROR OpenEJB.tomcat - Unable to deploy
collapsed ear in war
StandardEngine[Catalina].StandardHost[localhost].StandardContext[]
org.apache.xbean.propertyeditor.PropertyEditorException: Unable to resolve
class no-such-class
at
org.apache.xbean.propertyeditor.ClassEditor.toObjectImpl(ClassEditor.java:43)
at
org.apache.xbean.propertyeditor.AbstractConverter.toObject(AbstractConverter.java:86)
at
org.apache.xbean.propertyeditor.PropertyEditors.getValue(PropertyEditors.java:284)
at org.apache.xbean.recipe.RecipeHelper.convert(RecipeHelper.java:181)
at
org.apache.xbean.recipe.ObjectRecipe.extractConstructorArgs(ObjectRecipe.java:592)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:275)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at
org.apache.openejb.assembler.classic.Assembler.doCreateResource(Assembler.java:2970)
at
org.apache.openejb.assembler.classic.Assembler.createResource(Assembler.java:2803)
at
org.apache.openejb.config.ConfigurationFactory.doInstall(ConfigurationFactory.java:466)
at
org.apache.openejb.config.ConfigurationFactory.install(ConfigurationFactory.java:459)
at
org.apache.openejb.config.AutoConfig.installResource(AutoConfig.java:2194)
at
org.apache.openejb.config.AutoConfig.processApplicationResources(AutoConfig.java:1026)
at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:190)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:420)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1037)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1276)
at
org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1124)
at
org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:133)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5087)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:952)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1823)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:807)
Caused by: java.lang.ClassNotFoundException: no-such-class
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at
org.apache.tomee.catalina.TomEEWebappClassLoader.loadClass(TomEEWebappClassLoader.java:204)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forNameFW(Class.java:288)
at java.lang.Class.forName(Class.java:281)
at
[jira] [Commented] (TOMEE-2051) JTA 1.2 compliance: @Transactional.rollbackOn regression
[
https://issues.apache.org/jira/browse/TOMEE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034632#comment-16034632
]
Svetlin Zarev commented on TOMEE-2051:
--
[~romain.manni-bucau]Sure, I'll try to do it next week.
> JTA 1.2 compliance: @Transactional.rollbackOn regression
>
>
> Key: TOMEE-2051
> URL: https://issues.apache.org/jira/browse/TOMEE-2051
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> We introduced a regression with (I guess) TOMEE-2049.
> Test cases (transnational bean methods):
> {code}
> //[1] Does not work - transaction is not marked for roll back
> @Transactional(rollbackOn = RollBackException.class)
> public void withRollBackOnWithDeclaredRuntimeException() throws
> RollBackException {
> throw new RollBackException("Roll back because of me! - exception
> declared in throws clause");
> }
> //[2]Works as expected
> @Transactional(rollbackOn = RollBackException.class)
> public void withRollBackOnWithoutDeclaredRuntimeException() {
> throw new RollBackException("Roll back because of me! - exception not
> declared in throws clause");
> }
> {code}
> Where RollbackException is a **RuntimeException**.
> In the case where the runtime exception is declared in the throws clause, the
> transaction is not rolled back, although rollbackOn=RollbackException is set.
> The root cause is in
> {code}
> private static boolean isNotChecked(final Exception e, final
> Class[] exceptionTypes) {
> return RuntimeException.class.isInstance(e) &&
> (exceptionTypes.length == 0 ||
> !asList(exceptionTypes).contains(e.getClass()));
> }
> {code}
> Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
> passed from InterceptorBase:104
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2051) JTA 1.2 compliance: @Transactional.rollbackOn regression
[
https://issues.apache.org/jira/browse/TOMEE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2051:
-
Description:
We introduced a regression with (I guess) TOMEE-2049.
Test cases (transnational bean methods):
{code}
//[1] Does not work - transaction is not marked for roll back
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithDeclaredRuntimeException() throws
RollBackException {
throw new RollBackException("Roll back because of me! - exception
declared in throws clause");
}
//[2]Works as expected
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithoutDeclaredRuntimeException() {
throw new RollBackException("Roll back because of me! - exception not
declared in throws clause");
}
{code}
Where RollbackException is a **RuntimeException**.
In the case where the runtime exception is declared in the throws clause, the
transaction is not rolled back, although rollbackOn=RollbackException is set.
The root cause is in
{code}
private static boolean isNotChecked(final Exception e, final Class[]
exceptionTypes) {
return RuntimeException.class.isInstance(e) &&
(exceptionTypes.length == 0 || !asList(exceptionTypes).contains(e.getClass()));
}
{code}
Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
passed from InterceptorBase:104
was:
We introduced a regression with (I guess) TOMEE-2049.
Test cases:
Transnational bean methods:
{code}
//[1] Does not work - transaction is not marked for roll back
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithDeclaredRuntimeException() throws
RollBackException {
throw new RollBackException("Roll back because of me! - exception
declared in throws clause");
}
//[2]Works as expected
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithoutDeclaredRuntimeException() {
throw new RollBackException("Roll back because of me! - exception not
declared in throws clause");
}
{code}
Where RollbackException is a **RuntimeException**.
In the case where the runtime exception is declared in the throws clause, the
transaction is not rolled back, although rollbackOn=RollbackException is set.
The root cause is in
{code}
private static boolean isNotChecked(final Exception e, final Class[]
exceptionTypes) {
return RuntimeException.class.isInstance(e) &&
(exceptionTypes.length == 0 || !asList(exceptionTypes).contains(e.getClass()));
}
{code}
Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
passed from InterceptorBase:104
> JTA 1.2 compliance: @Transactional.rollbackOn regression
>
>
> Key: TOMEE-2051
> URL: https://issues.apache.org/jira/browse/TOMEE-2051
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> We introduced a regression with (I guess) TOMEE-2049.
> Test cases (transnational bean methods):
> {code}
> //[1] Does not work - transaction is not marked for roll back
> @Transactional(rollbackOn = RollBackException.class)
> public void withRollBackOnWithDeclaredRuntimeException() throws
> RollBackException {
> throw new RollBackException("Roll back because of me! - exception
> declared in throws clause");
> }
> //[2]Works as expected
> @Transactional(rollbackOn = RollBackException.class)
> public void withRollBackOnWithoutDeclaredRuntimeException() {
> throw new RollBackException("Roll back because of me! - exception not
> declared in throws clause");
> }
> {code}
> Where RollbackException is a **RuntimeException**.
> In the case where the runtime exception is declared in the throws clause, the
> transaction is not rolled back, although rollbackOn=RollbackException is set.
> The root cause is in
> {code}
> private static boolean isNotChecked(final Exception e, final
> Class[] exceptionTypes) {
> return RuntimeException.class.isInstance(e) &&
> (exceptionTypes.length == 0 ||
> !asList(exceptionTypes).contains(e.getClass()));
> }
> {code}
> Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
> passed from InterceptorBase:104
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2051) JTA 1.2 compliance: @Transactional.rollbackOn regression
[
https://issues.apache.org/jira/browse/TOMEE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2051:
-
Description:
We introduced a regression with (I guess) TOMEE-2049.
Test cases:
Transnational bean methods:
{code}
//[1] Does not work - transaction is not marked for roll back
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithDeclaredRuntimeException() throws
RollBackException {
throw new RollBackException("Roll back because of me! - exception
declared in throws clause");
}
//[2]Works as expected
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithoutDeclaredRuntimeException() {
throw new RollBackException("Roll back because of me! - exception not
declared in throws clause");
}
{code}
Where RollbackException is a **RuntimeException**.
In the case where the runtime exception is declared in the throws clause, the
transaction is not rolled back, although rollbackOn=RollbackException is set.
The root cause is in
{code}
private static boolean isNotChecked(final Exception e, final Class[]
exceptionTypes) {
return RuntimeException.class.isInstance(e) &&
(exceptionTypes.length == 0 || !asList(exceptionTypes).contains(e.getClass()));
}
{code}
Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
passed from InterceptorBase:104
was:
We introduced a regression with (I guess) TOMEE-2049.
Test cases:
Transnational bean methods:
{code}
//[1] Does not work - transaction is not marked for roll back
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithDeclaredRuntimeException() throws
RollBackException {
throw new RollBackException("Roll back because of me! - exception
declared in throws clause");
}
//[2]Works as expected
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithoutDeclaredRuntimeException() {
throw new RollBackException("Roll back because of me! - exception not
declared in throws clause");
}
{code}
Where RollbackException is a **RuntimeException**.
In the case where the runtime exception is declared in the throws clause, the
transaction is not rolled back, although rollbackOn=RollbackException is set.
The root cause is in
{code}
private static boolean isNotChecked(final Exception e, final Class[]
exceptionTypes) {
return RuntimeException.class.isInstance(e) &&
(exceptionTypes.length == 0 || !asList(exceptionTypes).contains(e.getClass()));
}
{code}
Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
> JTA 1.2 compliance: @Transactional.rollbackOn regression
>
>
> Key: TOMEE-2051
> URL: https://issues.apache.org/jira/browse/TOMEE-2051
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> We introduced a regression with (I guess) TOMEE-2049.
> Test cases:
> Transnational bean methods:
> {code}
> //[1] Does not work - transaction is not marked for roll back
> @Transactional(rollbackOn = RollBackException.class)
> public void withRollBackOnWithDeclaredRuntimeException() throws
> RollBackException {
> throw new RollBackException("Roll back because of me! - exception
> declared in throws clause");
> }
> //[2]Works as expected
> @Transactional(rollbackOn = RollBackException.class)
> public void withRollBackOnWithoutDeclaredRuntimeException() {
> throw new RollBackException("Roll back because of me! - exception not
> declared in throws clause");
> }
> {code}
> Where RollbackException is a **RuntimeException**.
> In the case where the runtime exception is declared in the throws clause, the
> transaction is not rolled back, although rollbackOn=RollbackException is set.
> The root cause is in
> {code}
> private static boolean isNotChecked(final Exception e, final
> Class[] exceptionTypes) {
> return RuntimeException.class.isInstance(e) &&
> (exceptionTypes.length == 0 ||
> !asList(exceptionTypes).contains(e.getClass()));
> }
> {code}
> Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
> passed from InterceptorBase:104
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2051) JTA 1.2 compliance: @Transactional.rollbackOn regression
[
https://issues.apache.org/jira/browse/TOMEE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2051:
-
Description:
We introduced a regression with (I guess) TOMEE-2049.
Test cases:
Transnational bean methods:
{code}
//[1] Does not work - transaction is not marked for roll back
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithDeclaredRuntimeException() throws
RollBackException {
throw new RollBackException("Roll back because of me! - exception
declared in throws clause");
}
//[2]Works as expected
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithoutDeclaredRuntimeException() {
throw new RollBackException("Roll back because of me! - exception not
declared in throws clause");
}
{code}
Where RollbackException is a **RuntimeException**.
In the case where the runtime exception is declared in the throws clause, the
transaction is not rolled back, although rollbackOn=RollbackException is set.
The root cause is in
{code}
private static boolean isNotChecked(final Exception e, final Class[]
exceptionTypes) {
return RuntimeException.class.isInstance(e) &&
(exceptionTypes.length == 0 || !asList(exceptionTypes).contains(e.getClass()));
}
{code}
Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
was:
We introduced a regression with (I guess) TOMEE-2049.
Test cases:
Transnational bean methods:
{code}
//[1] Does not work - transaction is not marked for roll back
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithDeclaredRuntimeException() throws
RollBackException {
throw new RollBackException("Roll back because of me! - exception
declared in throws clause");
}
//[2]Works as expected
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithoutDeclaredRuntimeException() {
throw new RollBackException("Roll back because of me! - exception not
declared in throws clause");
}
{code}
Where RollbackException is a **RuntimeException**.
In the case where the runtime exception is declared in the throws clause, the
transaction is not rolled back, although rollbackOn=RollbackException is set.
> JTA 1.2 compliance: @Transactional.rollbackOn regression
>
>
> Key: TOMEE-2051
> URL: https://issues.apache.org/jira/browse/TOMEE-2051
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> We introduced a regression with (I guess) TOMEE-2049.
> Test cases:
> Transnational bean methods:
> {code}
> //[1] Does not work - transaction is not marked for roll back
> @Transactional(rollbackOn = RollBackException.class)
> public void withRollBackOnWithDeclaredRuntimeException() throws
> RollBackException {
> throw new RollBackException("Roll back because of me! - exception
> declared in throws clause");
> }
> //[2]Works as expected
> @Transactional(rollbackOn = RollBackException.class)
> public void withRollBackOnWithoutDeclaredRuntimeException() {
> throw new RollBackException("Roll back because of me! - exception not
> declared in throws clause");
> }
> {code}
> Where RollbackException is a **RuntimeException**.
> In the case where the runtime exception is declared in the throws clause, the
> transaction is not rolled back, although rollbackOn=RollbackException is set.
> The root cause is in
> {code}
> private static boolean isNotChecked(final Exception e, final
> Class[] exceptionTypes) {
> return RuntimeException.class.isInstance(e) &&
> (exceptionTypes.length == 0 ||
> !asList(exceptionTypes).contains(e.getClass()));
> }
> {code}
> Here *exceptionTypes* is the passed value of "method.getExceptionTypes()"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TOMEE-2051) JTA 1.2 compliance: @Transactional.rollbackOn regression
Svetlin Zarev created TOMEE-2051:
Summary: JTA 1.2 compliance: @Transactional.rollbackOn regression
Key: TOMEE-2051
URL: https://issues.apache.org/jira/browse/TOMEE-2051
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
We introduced a regression with (I guess) TOMEE-2049.
Test cases:
Transnational bean methods:
{code}
//[1] Does not work - transaction is not marked for roll back
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithDeclaredRuntimeException() throws
RollBackException {
throw new RollBackException("Roll back because of me! - exception
declared in throws clause");
}
//[2]Works as expected
@Transactional(rollbackOn = RollBackException.class)
public void withRollBackOnWithoutDeclaredRuntimeException() {
throw new RollBackException("Roll back because of me! - exception not
declared in throws clause");
}
{code}
Where RollbackException is a **RuntimeException**.
In the case where the runtime exception is declared in the throws clause, the
transaction is not rolled back, although rollbackOn=RollbackException is set.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034515#comment-16034515
]
Svetlin Zarev edited comment on TOMEE-2050 at 6/2/17 11:15 AM:
---
No, I do not:
{code}
@WebServlet("/userTransaction")
public final class CdiTransactionaltest extends HttpServlet {
@Inject
TransactionalBean transactionalBean;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
final PrintWriter out = resp.getWriter();
resp.setContentType("text/plain");
try {
out.println("Testing with UserTransaction inside transactional
bean...");
transactionalBean.testWithTxRequiredAndUserTransaction();
} catch (Exception ex) {
out.println("Exception: " + ex);
ex.printStackTrace(out);
}
}
}
{code}
The main transaction is initiated and managed by the transactional intervceptor
was (Author: svetlinzarev):
No, I do not:
{code}
@WebServlet("/userTransaction")
public final class CdiTransactionaltest extends HttpServlet {
@Inject
TransactionalBean transactionalBean;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
final PrintWriter out = resp.getWriter();
resp.setContentType("text/plain");
try {
out.println("Testing with UserTransaction inside transactional
bean...");
transactionalBean.testWithTxRequiredAndUserTransaction();
} catch (Exception ex) {
out.println("Exception: " + ex);
ex.printStackTrace(out);
}
}
}
{code}
The main transaction is initiated by the transactional intervceptor
> JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
>
>
> Key: TOMEE-2050
> URL: https://issues.apache.org/jira/browse/TOMEE-2050
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: ROOT.war, sample.zip, sample.zip
>
>
> JTA 1.2, section 3.7:
> {code}
> If an attempt is made to call any method of the UserTransaction interface
> from within the scope of a bean or method annotated with @Transactional and a
> Transactional.TxType other than NOT_SUPPORTED or NEVER, an
> IllegalStateException must be thrown.
> {code}
> Instead TomEE throws:
> {code}
> 13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> javax.transaction.NotSupportedException: Nested Transactions are not supported
> 13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
> 13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
> ...
> ...
> ...
> 13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
> 13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
> 13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
> 13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
> 13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034515#comment-16034515
]
Svetlin Zarev commented on TOMEE-2050:
--
No, I do not:
{code}
@WebServlet("/userTransaction")
public final class CdiTransactionaltest extends HttpServlet {
@Inject
TransactionalBean transactionalBean;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
final PrintWriter out = resp.getWriter();
resp.setContentType("text/plain");
try {
out.println("Testing with UserTransaction inside transactional
bean...");
transactionalBean.testWithTxRequiredAndUserTransaction();
} catch (Exception ex) {
out.println("Exception: " + ex);
ex.printStackTrace(out);
}
}
}
{code}
The main transaction is initiated by the transactional intervceptor
> JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
>
>
> Key: TOMEE-2050
> URL: https://issues.apache.org/jira/browse/TOMEE-2050
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: ROOT.war, sample.zip, sample.zip
>
>
> JTA 1.2, section 3.7:
> {code}
> If an attempt is made to call any method of the UserTransaction interface
> from within the scope of a bean or method annotated with @Transactional and a
> Transactional.TxType other than NOT_SUPPORTED or NEVER, an
> IllegalStateException must be thrown.
> {code}
> Instead TomEE throws:
> {code}
> 13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> javax.transaction.NotSupportedException: Nested Transactions are not supported
> 13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
> 13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
> ...
> ...
> ...
> 13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
> 13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
> 13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
> 13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
> 13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2050:
-
Attachment: ROOT.war
> JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
>
>
> Key: TOMEE-2050
> URL: https://issues.apache.org/jira/browse/TOMEE-2050
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: ROOT.war, sample.zip, sample.zip
>
>
> JTA 1.2, section 3.7:
> {code}
> If an attempt is made to call any method of the UserTransaction interface
> from within the scope of a bean or method annotated with @Transactional and a
> Transactional.TxType other than NOT_SUPPORTED or NEVER, an
> IllegalStateException must be thrown.
> {code}
> Instead TomEE throws:
> {code}
> 13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> javax.transaction.NotSupportedException: Nested Transactions are not supported
> 13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
> 13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
> ...
> ...
> ...
> 13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
> 13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
> 13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
> 13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
> 13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2050:
-
Attachment: sample.zip
> JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
>
>
> Key: TOMEE-2050
> URL: https://issues.apache.org/jira/browse/TOMEE-2050
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: ROOT.war, sample.zip, sample.zip
>
>
> JTA 1.2, section 3.7:
> {code}
> If an attempt is made to call any method of the UserTransaction interface
> from within the scope of a bean or method annotated with @Transactional and a
> Transactional.TxType other than NOT_SUPPORTED or NEVER, an
> IllegalStateException must be thrown.
> {code}
> Instead TomEE throws:
> {code}
> 13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> javax.transaction.NotSupportedException: Nested Transactions are not supported
> 13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
> 13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
> ...
> ...
> ...
> 13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
> 13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
> 13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
> 13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
> 13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034509#comment-16034509
]
Svetlin Zarev edited comment on TOMEE-2050 at 6/2/17 11:09 AM:
---
Well, but the attached WAR fails with the exception mentioned above when
executed on vanilla TomEE. Just drop the ROOT.war in webapps and request
http://localhost:8080/
was (Author: svetlinzarev):
Well, but the attached WAR fails with the exception mentioned above when
executed on vanilla TomEE. Just frop th eROOT.war in webapps and request
http://localhost:8080/
> JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
>
>
> Key: TOMEE-2050
> URL: https://issues.apache.org/jira/browse/TOMEE-2050
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> JTA 1.2, section 3.7:
> {code}
> If an attempt is made to call any method of the UserTransaction interface
> from within the scope of a bean or method annotated with @Transactional and a
> Transactional.TxType other than NOT_SUPPORTED or NEVER, an
> IllegalStateException must be thrown.
> {code}
> Instead TomEE throws:
> {code}
> 13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> javax.transaction.NotSupportedException: Nested Transactions are not supported
> 13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
> 13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
> ...
> ...
> ...
> 13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
> 13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
> 13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
> 13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
> 13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034509#comment-16034509
]
Svetlin Zarev commented on TOMEE-2050:
--
Well, but the attached WAR fails with the exception mentioned above when
executed on vanilla TomEE. Just frop th eROOT.war in webapps and request
http://localhost:8080/
> JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
>
>
> Key: TOMEE-2050
> URL: https://issues.apache.org/jira/browse/TOMEE-2050
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> JTA 1.2, section 3.7:
> {code}
> If an attempt is made to call any method of the UserTransaction interface
> from within the scope of a bean or method annotated with @Transactional and a
> Transactional.TxType other than NOT_SUPPORTED or NEVER, an
> IllegalStateException must be thrown.
> {code}
> Instead TomEE throws:
> {code}
> 13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> javax.transaction.NotSupportedException: Nested Transactions are not supported
> 13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
> 13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
> ...
> ...
> ...
> 13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
> 13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
> 13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
> 13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
> 13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034495#comment-16034495
]
Svetlin Zarev edited comment on TOMEE-2050 at 6/2/17 10:55 AM:
---
Servlet:
{code}
@WebServlet("/userTransaction")
public final class CdiTransactionaltest extends HttpServlet {
@Resource
UserTransaction transaction;
@Inject
TransactionalBean transactionalBean;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
final PrintWriter out = resp.getWriter();
resp.setContentType("text/plain");
//other test cases here
try {
out.println("Testing with UserTransaction inside transactional
bean...");
transactionalBean.testWithTxRequiredAndUserTransaction();
} catch (Exception ex) {
out.println("Exception: " + ex);
ex.printStackTrace(out);
}
}
}
{code}
Transactional bean:
{code}
@Default
public class TransactionalBean {
@Resource
UserTransaction userTransaction;
//other test methods here
@Transactional(TxType.REQUIRED)
public void testWithTxRequiredAndUserTransaction() throws Exception {
userTransaction.begin();
userTransaction.commit();
}
}
{code}
Stack trace from test case:
{code}
Testing with UserTransaction inside transactional bean...
Exception: javax.transaction.NotSupportedException: Nested Transactions are not
supported
javax.transaction.NotSupportedException: Nested Transactions are not supported
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
at
org.example.TransactionalBean.testWithTxRequiredAndUserTransaction(TransactionalBean.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
at
org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
at
org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
at
org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
at
org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.webbeans.component.InterceptorBean.intercept(InterceptorBean.java:136)
at
org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:63)
at
org.apache.webbeans.intercept.DefaultInterceptorHandler.invoke(DefaultInterceptorHandler.java:139)
at
org.example.TransactionalBean$$OwbInterceptProxy0.testWithTxRequiredAndUserTransaction(org/example/TransactionalBean.java)
at org.example.CdiTransactionaltest.doGet(CdiTransactionaltest.java:81)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
{code}
Attaching zip with sample app (war + source)
was (Author: svetlinzarev):
Servlet:
{code}
@WebServlet("/userTransaction")
public final class CdiTransactionaltest extends HttpServlet {
@Resource
UserTransaction transaction;
@Inject
TransactionalBean transactionalBean;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
final PrintWriter out = resp.getWriter();
resp.setContentType("text/plain");
//other test cases here
try {
out.println("Testing with UserTransaction inside transactional
bean...");
transactionalBean.testWithTxRequiredAndUserTransaction();
} catch (Exception ex) {
out.println("Exception: " + ex);
ex.printStackTrace(out);
}
}
}
{code}
Transactional bean:
{code}
@Default
public class TransactionalBean {
@Resource
UserTransaction userTransaction;
//other test methods here
@Transactional(TxType.REQUIRED)
public void testWithTxRequiredAndUserTransaction() throws Exception {
userTransaction.begin();
userTransaction.commit();
[jira] [Updated] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2050:
-
Attachment: sample.zip
> JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
>
>
> Key: TOMEE-2050
> URL: https://issues.apache.org/jira/browse/TOMEE-2050
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> JTA 1.2, section 3.7:
> {code}
> If an attempt is made to call any method of the UserTransaction interface
> from within the scope of a bean or method annotated with @Transactional and a
> Transactional.TxType other than NOT_SUPPORTED or NEVER, an
> IllegalStateException must be thrown.
> {code}
> Instead TomEE throws:
> {code}
> 13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> javax.transaction.NotSupportedException: Nested Transactions are not supported
> 13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
> 13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
> ...
> ...
> ...
> 13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
> 13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
> 13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
> 13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
> 13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
[
https://issues.apache.org/jira/browse/TOMEE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16034495#comment-16034495
]
Svetlin Zarev commented on TOMEE-2050:
--
Servlet:
{code}
@WebServlet("/userTransaction")
public final class CdiTransactionaltest extends HttpServlet {
@Resource
UserTransaction transaction;
@Inject
TransactionalBean transactionalBean;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
final PrintWriter out = resp.getWriter();
resp.setContentType("text/plain");
//other test cases here
try {
out.println("Testing with UserTransaction inside transactional
bean...");
transactionalBean.testWithTxRequiredAndUserTransaction();
} catch (Exception ex) {
out.println("Exception: " + ex);
ex.printStackTrace(out);
}
}
}
{code}
Transactional bean:
{code}
@Default
public class TransactionalBean {
@Resource
UserTransaction userTransaction;
//other test methods here
@Transactional(TxType.REQUIRED)
public void testWithTxRequiredAndUserTransaction() throws Exception {
userTransaction.begin();
userTransaction.commit();
}
}
{code}
Attaching zip with sample app (war + source)
> JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
>
>
> Key: TOMEE-2050
> URL: https://issues.apache.org/jira/browse/TOMEE-2050
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> JTA 1.2, section 3.7:
> {code}
> If an attempt is made to call any method of the UserTransaction interface
> from within the scope of a bean or method annotated with @Transactional and a
> Transactional.TxType other than NOT_SUPPORTED or NEVER, an
> IllegalStateException must be thrown.
> {code}
> Instead TomEE throws:
> {code}
> 13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> javax.transaction.NotSupportedException: Nested Transactions are not supported
> 13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
> 13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
> ...
> ...
> ...
> 13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
> 13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
> 13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
> 13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
> 13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TOMEE-2050) JTA 1.2 compliance: Calling UserTransaction methods from @Transactional bean
Svetlin Zarev created TOMEE-2050:
Summary: JTA 1.2 compliance: Calling UserTransaction methods from
@Transactional bean
Key: TOMEE-2050
URL: https://issues.apache.org/jira/browse/TOMEE-2050
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
JTA 1.2, section 3.7:
{code}
If an attempt is made to call any method of the UserTransaction interface from
within the scope of a bean or method annotated with @Transactional and a
Transactional.TxType other than NOT_SUPPORTED or NEVER, an
IllegalStateException must be thrown.
{code}
Instead TomEE throws:
{code}
13:38:03.710 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
javax.transaction.NotSupportedException: Nested Transactions are not supported
13:38:03.713 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:157)
13:38:03.716 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.begin(TransactionManagerImpl.java:152)
...
...
...
13:38:03.737 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.intercept.AbstractInvocationContext.directProceed(AbstractInvocationContext.java:113)
13:38:03.758 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.intercept.AbstractInvocationContext.proceed(AbstractInvocationContext.java:106)
13:38:03.761 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:67)
13:38:03.766 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:67)
13:38:03.770 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.cdi.transactional.RequiredInterceptor.intercept(RequiredInterceptor.java:35)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (TOMEE-2048) JTA 1.2 compliance: TxNever called from within transaction must throw TransactionalException
[
https://issues.apache.org/jira/browse/TOMEE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev reopened TOMEE-2048:
--
Thanks, that was awesomely fast ! But it must have a nested
InvalidTransactionException, not a Remote Exception:
{code}
try {
return super.intercept(ic);
} catch (final RemoteException re) {
throw new TransactionalException(re.getMessage(), re);
}
{code}
>From the spec: If called inside a transaction context, a
>TransactionalException with a nested InvalidTransactionException must be thrown
> JTA 1.2 compliance: TxNever called from within transaction must throw
> TransactionalException
>
>
> Key: TOMEE-2048
> URL: https://issues.apache.org/jira/browse/TOMEE-2048
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>Assignee: Romain Manni-Bucau
> Fix For: 7.0.4
>
>
> JTA 1.2 spec mandates that if a managed bean with TxType.NEVER is called from
> within a transaction, A TransactionalException with nested
> InvalidTransactionException must be thrown.
> JTA 1.2 spec, section 3.7:
> {code}
> TxType.NEVER: If called outside a transaction context, managed bean method
> execution must then continue outside a transaction context.
> If called inside a transaction context, a TransactionalException with a
> nested InvalidTransactionException must be thrown.
> {code}
> But instead, TomEE throws
> {code}
> 11:58:36.337 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
> java.rmi.RemoteException: Transactions not supported
> 11:58:36.339 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.core.transaction.TxNever.(TxNever.java:47)
> 11:58:36.342 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.NeverInterceptor.getPolicy(NeverInterceptor.java:41)
> 11:58:36.345 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:66)
> 11:58:36.348 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.openejb.cdi.transactional.NeverInterceptor.intercept(NeverInterceptor.java:36)
> 11:58:36.352 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:58:36.355 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 11:58:36.358 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:58:36.361 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> java.lang.reflect.Method.invoke(Method.java:606)
> 11:58:36.380 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.component.InterceptorBean.intercept(InterceptorBean.java:136)
> 11:58:36.385 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:63)
> 11:58:36.390 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
> org.apache.webbeans.intercept.DefaultInterceptorHandler.invoke(DefaultInterceptorHandler.java:139)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TOMEE-2049) JTA 1.2 compliance:The combination of @Transactional.dontRollbackOn=XXX,rollbackOn=XXX is not respected
Svetlin Zarev created TOMEE-2049:
Summary: JTA 1.2 compliance:The combination of
@Transactional.dontRollbackOn=XXX,rollbackOn=XXX is not respected
Key: TOMEE-2049
URL: https://issues.apache.org/jira/browse/TOMEE-2049
Project: TomEE
Issue Type: Bug
Reporter: Svetlin Zarev
Imagine you have a cdi bean method annotated with
{code}
@Transactional(rollbackOn={RollBackException.class},
dontRollbackOn={RollBackException.class})
{code}
According to the JTA 1.2 spec, section 3.7, the transaction must not be marked
for roll back:
{code}
The following will cause the transaction to be marked for rollback for all
runtime exceptions and all SQLException types except for SQLWarning.
@Transactional(rollbackOn={SQLException.class},
dontRollbackOn={SQLWarning.class})
{code}
Yet TomEE marks the transaction for roll back.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2049) JTA 1.2 compliance: The combination of @Transactional.dontRollbackOn=XXX,rollbackOn=XXX is not respected
[
https://issues.apache.org/jira/browse/TOMEE-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2049:
-
Summary: JTA 1.2 compliance: The combination of
@Transactional.dontRollbackOn=XXX,rollbackOn=XXX is not respected (was: JTA
1.2 compliance:The combination of
@Transactional.dontRollbackOn=XXX,rollbackOn=XXX is not respected)
> JTA 1.2 compliance: The combination of
> @Transactional.dontRollbackOn=XXX,rollbackOn=XXX is not respected
> --
>
> Key: TOMEE-2049
> URL: https://issues.apache.org/jira/browse/TOMEE-2049
> Project: TomEE
> Issue Type: Bug
>Reporter: Svetlin Zarev
>
> Imagine you have a cdi bean method annotated with
> {code}
> @Transactional(rollbackOn={RollBackException.class},
> dontRollbackOn={RollBackException.class})
> {code}
> According to the JTA 1.2 spec, section 3.7, the transaction must not be
> marked for roll back:
> {code}
> The following will cause the transaction to be marked for rollback for all
> runtime exceptions and all SQLException types except for SQLWarning.
> @Transactional(rollbackOn={SQLException.class},
> dontRollbackOn={SQLWarning.class})
> {code}
> Yet TomEE marks the transaction for roll back.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2048) JTA 1.2 compliance: TxNever called from within transaction must throw TransactionalException
[
https://issues.apache.org/jira/browse/TOMEE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2048:
-
Description:
JTA 1.2 spec mandates that if a managed bean with TxType.NEVER is called from
within a transaction, A TransactionalException with nested
InvalidTransactionException must be thrown.
JTA 1.2 spec, section 3.7:
{code}
TxType.NEVER: If called outside a transaction context, managed bean method
execution must then continue outside a transaction context.
If called inside a transaction context, a TransactionalException with a nested
InvalidTransactionException must be thrown.
{code}
But instead, TomEE throws
{code}
11:58:36.337 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
java.rmi.RemoteException: Transactions not supported
11:58:36.339 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.core.transaction.TxNever.(TxNever.java:47)
11:58:36.342 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.cdi.transactional.NeverInterceptor.getPolicy(NeverInterceptor.java:41)
11:58:36.345 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:66)
11:58:36.348 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.cdi.transactional.NeverInterceptor.intercept(NeverInterceptor.java:36)
11:58:36.352 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:58:36.355 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
11:58:36.358 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:58:36.361 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
java.lang.reflect.Method.invoke(Method.java:606)
11:58:36.380 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.component.InterceptorBean.intercept(InterceptorBean.java:136)
11:58:36.385 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:63)
11:58:36.390 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.intercept.DefaultInterceptorHandler.invoke(DefaultInterceptorHandler.java:139)
{code}
was:
JTA 1.2 spec mandates that if a managed bean with TxType.NEVER is called from
within a transaction, A TransactionalException with nested
InvalidTransactionException must be thrown:
{code}
TxType.NEVER: If called outside a transaction context, managed bean method
execution must then continue outside a transaction context.
If called inside a transaction context, a TransactionalException with a nested
InvalidTransactionException must be thrown
{code}
But instead, TomEE throws
{code}
11:58:36.337 [http-nio-8080-exec-7] ERROR java.lang.Throwable -
java.rmi.RemoteException: Transactions not supported
11:58:36.339 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.core.transaction.TxNever.(TxNever.java:47)
11:58:36.342 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.cdi.transactional.NeverInterceptor.getPolicy(NeverInterceptor.java:41)
11:58:36.345 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.cdi.transactional.InterceptorBase.intercept(InterceptorBase.java:66)
11:58:36.348 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.openejb.cdi.transactional.NeverInterceptor.intercept(NeverInterceptor.java:36)
11:58:36.352 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:58:36.355 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
11:58:36.358 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:58:36.361 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
java.lang.reflect.Method.invoke(Method.java:606)
11:58:36.380 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.component.InterceptorBean.intercept(InterceptorBean.java:136)
11:58:36.385 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.intercept.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:63)
11:58:36.390 [http-nio-8080-exec-7] ERROR java.lang.Throwable - at
org.apache.webbeans.intercept.DefaultInterceptorHandler.invoke(DefaultInterceptorHandler.java:139)
{code}
> JTA 1.2 compliance: TxNever called from within
[jira] [Resolved] (TOMEE-2043) Thread local transactions are left open across requests
[
https://issues.apache.org/jira/browse/TOMEE-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev resolved TOMEE-2043.
--
Resolution: Not A Problem
> Thread local transactions are left open across requests
> ---
>
> Key: TOMEE-2043
> URL: https://issues.apache.org/jira/browse/TOMEE-2043
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.3
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> @Transactional CDI bean methods annotated with
> @Transactional(dontRollbackOn = SomeException.class) do not commit the
> transaction at the end of the request/response cycle when the SomeException
> exception is thrown. As a result the thread local transaction object is
> preserved across requests which makes unrelated requests to fail with "Nested
> transactions are not supported".
> Sample application that reproduces the issue is attached to the ticket. Just
> request the application several times and observe how the output is changing.
> Sample valve that can be used to demonstrate the issue:
> {code}
> public final class LeakedTransactionDetectionValve extends ValveBase {
> private static final Logger logger =
> Logger.getLogger(LeakedTransactionDetectionValve.class.getName());
> @Override
> public void invoke(Request request, Response response) throws
> IOException, ServletException {
> boolean hasActiveTransaction = false;
> try {
> final Collection transactionsBeforeRequest =
> getTransactions();
> for (Transaction transaction : transactionsBeforeRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> hasActiveTransaction = true;
> break;
> }
> }
> } catch (Exception ex) {
> //no-op
> }
> getNext().invoke(request, response);
> if (!hasActiveTransaction) {
> try {
> final Collection transactionsAfterRequest =
> getTransactions();
> for (Transaction transaction : transactionsAfterRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> logger.log(Level.SEVERE, "Found active transaction: "
> + request.getRequestURI()
> + "?"
> + request.getQueryString()
> );
> }
> }
> } catch (Exception ex) {
> logger.log(Level.SEVERE, "Failed to determine thread local
> transaction status.", ex);
> }
> }
> }
> Collection getTransactions() throws NoSuchFieldException,
> IllegalAccessException {
> final Field threadLocalsField =
> Thread.class.getDeclaredField("threadLocals");
> threadLocalsField.setAccessible(true);
> final Object threadLocals =
> threadLocalsField.get(Thread.currentThread());
> final Field tableField =
> threadLocals.getClass().getDeclaredField("table");
> tableField.setAccessible(true);
> final Object table = tableField.get(threadLocals);
> final Collection transactions = new LinkedList<>();
> for (int i = 0; i < Array.getLength(table); i++) {
> final Object entry = Array.get(table, i);
> if (null != entry) {
> final Field valueField =
> entry.getClass().getDeclaredField("value");
> valueField.setAccessible(true);
> final Object value = valueField.get(entry);
> if (value instanceof Transaction) {
> transactions.add((Transaction) value);
> }
> }
> }
> return transactions;
> }
> {code}
> PS: in addition to the issue above, the
> org.apache.openejb.cdi.transactional.InterceptorBase must not wrap the
> exception specified in the "donotRollbackOn" attribute inside
> TransactionalException
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TOMEE-2043) Thread local transactions are left open across requests
[
https://issues.apache.org/jira/browse/TOMEE-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032900#comment-16032900
]
Svetlin Zarev commented on TOMEE-2043:
--
I agree. Do you think that clearing the thread local (and not committing the
transaction) and logging an error is OK ? My point is that such state should
not be randomly carried across requests - a bug in one request should not make
other requests to fail.
> Thread local transactions are left open across requests
> ---
>
> Key: TOMEE-2043
> URL: https://issues.apache.org/jira/browse/TOMEE-2043
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.3
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> @Transactional CDI bean methods annotated with
> @Transactional(dontRollbackOn = SomeException.class) do not commit the
> transaction at the end of the request/response cycle when the SomeException
> exception is thrown. As a result the thread local transaction object is
> preserved across requests which makes unrelated requests to fail with "Nested
> transactions are not supported".
> Sample application that reproduces the issue is attached to the ticket. Just
> request the application several times and observe how the output is changing.
> Sample valve that can be used to demonstrate the issue:
> {code}
> public final class LeakedTransactionDetectionValve extends ValveBase {
> private static final Logger logger =
> Logger.getLogger(LeakedTransactionDetectionValve.class.getName());
> @Override
> public void invoke(Request request, Response response) throws
> IOException, ServletException {
> boolean hasActiveTransaction = false;
> try {
> final Collection transactionsBeforeRequest =
> getTransactions();
> for (Transaction transaction : transactionsBeforeRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> hasActiveTransaction = true;
> break;
> }
> }
> } catch (Exception ex) {
> //no-op
> }
> getNext().invoke(request, response);
> if (!hasActiveTransaction) {
> try {
> final Collection transactionsAfterRequest =
> getTransactions();
> for (Transaction transaction : transactionsAfterRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> logger.log(Level.SEVERE, "Found active transaction: "
> + request.getRequestURI()
> + "?"
> + request.getQueryString()
> );
> }
> }
> } catch (Exception ex) {
> logger.log(Level.SEVERE, "Failed to determine thread local
> transaction status.", ex);
> }
> }
> }
> Collection getTransactions() throws NoSuchFieldException,
> IllegalAccessException {
> final Field threadLocalsField =
> Thread.class.getDeclaredField("threadLocals");
> threadLocalsField.setAccessible(true);
> final Object threadLocals =
> threadLocalsField.get(Thread.currentThread());
> final Field tableField =
> threadLocals.getClass().getDeclaredField("table");
> tableField.setAccessible(true);
> final Object table = tableField.get(threadLocals);
> final Collection transactions = new LinkedList<>();
> for (int i = 0; i < Array.getLength(table); i++) {
> final Object entry = Array.get(table, i);
> if (null != entry) {
> final Field valueField =
> entry.getClass().getDeclaredField("value");
> valueField.setAccessible(true);
> final Object value = valueField.get(entry);
> if (value instanceof Transaction) {
> transactions.add((Transaction) value);
> }
> }
> }
> return transactions;
> }
> {code}
> PS: in addition to the issue above, the
> org.apache.openejb.cdi.transactional.InterceptorBase must not wrap the
> exception specified in the "donotRollbackOn" attribute inside
> TransactionalException
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (TOMEE-2043) Thread local transactions are left open across requests
[
https://issues.apache.org/jira/browse/TOMEE-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032853#comment-16032853
]
Svetlin Zarev edited comment on TOMEE-2043 at 6/1/17 11:53 AM:
---
Your test case passes because the transaction is started in the TxRequired
policy. While my sample app fails, because the transaction is ".begin()"ed
manually in the servlet:
{code}
transaction.begin();
transactionalBean.withDontRollbackOn();
transaction.commit();
{code}
ThRequired policy:
{code}
public void commit() throws ApplicationException, SystemException {
// only commit if we started the transaction
if (clientTx == null) {
completeTransaction(currentTx);
} else {
fireNonTransactionalCompletion();
}
}
{code}
So in the junit test case, the execution goes to the "clientTx == null" branch,
while in my case it goes to " fireNonTransactionalCompletion();" IMO that's
fine in all cases except for if this is the outermost interceptor, because in
that case there is no one to complete the transaction.
What do you think ?
was (Author: svetlinzarev):
Your test case passes because the transaction is started in the TxRequired
policy. While may sample app fails, because the transaction is ".begin()"ed
manually in the servlet:
{code}
transaction.begin();
transactionalBean.withDontRollbackOn();
transaction.commit();
{code}
ThRequired policy:
{code}
public void commit() throws ApplicationException, SystemException {
// only commit if we started the transaction
if (clientTx == null) {
completeTransaction(currentTx);
} else {
fireNonTransactionalCompletion();
}
}
{code}
So in the junit test case, the execution goes to the "clientTx == null" branch,
while in my case it goes to " fireNonTransactionalCompletion();" IMO that's
fine in all cases except for if this is the outermost interceptor, because in
that case there is no one to complete the transaction.
> Thread local transactions are left open across requests
> ---
>
> Key: TOMEE-2043
> URL: https://issues.apache.org/jira/browse/TOMEE-2043
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.3
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> @Transactional CDI bean methods annotated with
> @Transactional(dontRollbackOn = SomeException.class) do not commit the
> transaction at the end of the request/response cycle when the SomeException
> exception is thrown. As a result the thread local transaction object is
> preserved across requests which makes unrelated requests to fail with "Nested
> transactions are not supported".
> Sample application that reproduces the issue is attached to the ticket. Just
> request the application several times and observe how the output is changing.
> Sample valve that can be used to demonstrate the issue:
> {code}
> public final class LeakedTransactionDetectionValve extends ValveBase {
> private static final Logger logger =
> Logger.getLogger(LeakedTransactionDetectionValve.class.getName());
> @Override
> public void invoke(Request request, Response response) throws
> IOException, ServletException {
> boolean hasActiveTransaction = false;
> try {
> final Collection transactionsBeforeRequest =
> getTransactions();
> for (Transaction transaction : transactionsBeforeRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> hasActiveTransaction = true;
> break;
> }
> }
> } catch (Exception ex) {
> //no-op
> }
> getNext().invoke(request, response);
> if (!hasActiveTransaction) {
> try {
> final Collection transactionsAfterRequest =
> getTransactions();
> for (Transaction transaction : transactionsAfterRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> logger.log(Level.SEVERE, "Found active transaction: "
> + request.getRequestURI()
> + "?"
> + request.getQueryString()
> );
> }
> }
> } catch (Exception ex) {
> logger.log(Level.SEVERE, "Failed to determine thread local
> transaction status.", ex);
> }
> }
> }
> Collection getTransactions() throws NoSuchFieldException,
> IllegalAccessException {
> final Field threadLocalsField =
> Thread.class.getDeclaredField("threadLocals");
>
[jira] [Commented] (TOMEE-2043) Thread local transactions are left open across requests
[
https://issues.apache.org/jira/browse/TOMEE-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032853#comment-16032853
]
Svetlin Zarev commented on TOMEE-2043:
--
Your test case passes because the transaction is started in the TxRequired
policy. While may sample app fails, because the transaction is ".begin()"ed
manually in the servlet:
{code}
transaction.begin();
transactionalBean.withDontRollbackOn();
transaction.commit();
{code}
ThRequired policy:
{code}
public void commit() throws ApplicationException, SystemException {
// only commit if we started the transaction
if (clientTx == null) {
completeTransaction(currentTx);
} else {
fireNonTransactionalCompletion();
}
}
{code}
So in the junit test case, the execution goes to the "clientTx == null" branch,
while in my case it goes to " fireNonTransactionalCompletion();" IMO that's
fine in all cases except for if this is the outermost interceptor, because in
that case there is no one to complete the transaction.
> Thread local transactions are left open across requests
> ---
>
> Key: TOMEE-2043
> URL: https://issues.apache.org/jira/browse/TOMEE-2043
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.3
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> @Transactional CDI bean methods annotated with
> @Transactional(dontRollbackOn = SomeException.class) do not commit the
> transaction at the end of the request/response cycle when the SomeException
> exception is thrown. As a result the thread local transaction object is
> preserved across requests which makes unrelated requests to fail with "Nested
> transactions are not supported".
> Sample application that reproduces the issue is attached to the ticket. Just
> request the application several times and observe how the output is changing.
> Sample valve that can be used to demonstrate the issue:
> {code}
> public final class LeakedTransactionDetectionValve extends ValveBase {
> private static final Logger logger =
> Logger.getLogger(LeakedTransactionDetectionValve.class.getName());
> @Override
> public void invoke(Request request, Response response) throws
> IOException, ServletException {
> boolean hasActiveTransaction = false;
> try {
> final Collection transactionsBeforeRequest =
> getTransactions();
> for (Transaction transaction : transactionsBeforeRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> hasActiveTransaction = true;
> break;
> }
> }
> } catch (Exception ex) {
> //no-op
> }
> getNext().invoke(request, response);
> if (!hasActiveTransaction) {
> try {
> final Collection transactionsAfterRequest =
> getTransactions();
> for (Transaction transaction : transactionsAfterRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> logger.log(Level.SEVERE, "Found active transaction: "
> + request.getRequestURI()
> + "?"
> + request.getQueryString()
> );
> }
> }
> } catch (Exception ex) {
> logger.log(Level.SEVERE, "Failed to determine thread local
> transaction status.", ex);
> }
> }
> }
> Collection getTransactions() throws NoSuchFieldException,
> IllegalAccessException {
> final Field threadLocalsField =
> Thread.class.getDeclaredField("threadLocals");
> threadLocalsField.setAccessible(true);
> final Object threadLocals =
> threadLocalsField.get(Thread.currentThread());
> final Field tableField =
> threadLocals.getClass().getDeclaredField("table");
> tableField.setAccessible(true);
> final Object table = tableField.get(threadLocals);
> final Collection transactions = new LinkedList<>();
> for (int i = 0; i < Array.getLength(table); i++) {
> final Object entry = Array.get(table, i);
> if (null != entry) {
> final Field valueField =
> entry.getClass().getDeclaredField("value");
> valueField.setAccessible(true);
> final Object value = valueField.get(entry);
> if (value instanceof Transaction) {
> transactions.add((Transaction) value);
> }
> }
> }
> return transactions;
> }
> {code}
> PS: in addition to the issue above, the
>
[jira] [Commented] (TOMEE-2043) Thread local transactions are left open across requests
[
https://issues.apache.org/jira/browse/TOMEE-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032699#comment-16032699
]
Svetlin Zarev commented on TOMEE-2043:
--
Sure, I'll try to update the test
> Thread local transactions are left open across requests
> ---
>
> Key: TOMEE-2043
> URL: https://issues.apache.org/jira/browse/TOMEE-2043
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 7.0.3
>Reporter: Svetlin Zarev
> Attachments: sample.zip
>
>
> @Transactional CDI bean methods annotated with
> @Transactional(dontRollbackOn = SomeException.class) do not commit the
> transaction at the end of the request/response cycle when the SomeException
> exception is thrown. As a result the thread local transaction object is
> preserved across requests which makes unrelated requests to fail with "Nested
> transactions are not supported".
> Sample application that reproduces the issue is attached to the ticket. Just
> request the application several times and observe how the output is changing.
> Sample valve that can be used to demonstrate the issue:
> {code}
> public final class LeakedTransactionDetectionValve extends ValveBase {
> private static final Logger logger =
> Logger.getLogger(LeakedTransactionDetectionValve.class.getName());
> @Override
> public void invoke(Request request, Response response) throws
> IOException, ServletException {
> boolean hasActiveTransaction = false;
> try {
> final Collection transactionsBeforeRequest =
> getTransactions();
> for (Transaction transaction : transactionsBeforeRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> hasActiveTransaction = true;
> break;
> }
> }
> } catch (Exception ex) {
> //no-op
> }
> getNext().invoke(request, response);
> if (!hasActiveTransaction) {
> try {
> final Collection transactionsAfterRequest =
> getTransactions();
> for (Transaction transaction : transactionsAfterRequest) {
> if (transaction.getStatus() == Status.STATUS_ACTIVE) {
> logger.log(Level.SEVERE, "Found active transaction: "
> + request.getRequestURI()
> + "?"
> + request.getQueryString()
> );
> }
> }
> } catch (Exception ex) {
> logger.log(Level.SEVERE, "Failed to determine thread local
> transaction status.", ex);
> }
> }
> }
> Collection getTransactions() throws NoSuchFieldException,
> IllegalAccessException {
> final Field threadLocalsField =
> Thread.class.getDeclaredField("threadLocals");
> threadLocalsField.setAccessible(true);
> final Object threadLocals =
> threadLocalsField.get(Thread.currentThread());
> final Field tableField =
> threadLocals.getClass().getDeclaredField("table");
> tableField.setAccessible(true);
> final Object table = tableField.get(threadLocals);
> final Collection transactions = new LinkedList<>();
> for (int i = 0; i < Array.getLength(table); i++) {
> final Object entry = Array.get(table, i);
> if (null != entry) {
> final Field valueField =
> entry.getClass().getDeclaredField("value");
> valueField.setAccessible(true);
> final Object value = valueField.get(entry);
> if (value instanceof Transaction) {
> transactions.add((Transaction) value);
> }
> }
> }
> return transactions;
> }
> {code}
> PS: in addition to the issue above, the
> org.apache.openejb.cdi.transactional.InterceptorBase must not wrap the
> exception specified in the "donotRollbackOn" attribute inside
> TransactionalException
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TOMEE-2043) Thread local transactions are left open across requests
[
https://issues.apache.org/jira/browse/TOMEE-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svetlin Zarev updated TOMEE-2043:
-
Description:
@Transactional CDI bean methods annotated with
@Transactional(dontRollbackOn = SomeException.class) do not commit the
transaction at the end of the request/response cycle when the SomeException
exception is thrown. As a result the thread local transaction object is
preserved across requests which makes unrelated requests to fail with "Nested
transactions are not supported".
Sample application that reproduces the issue is attached to the ticket. Just
request the application several times and observe how the output is changing.
Sample valve that can be used to demonstrate the issue:
{code}
public final class LeakedTransactionDetectionValve extends ValveBase {
private static final Logger logger =
Logger.getLogger(LeakedTransactionDetectionValve.class.getName());
@Override
public void invoke(Request request, Response response) throws IOException,
ServletException {
boolean hasActiveTransaction = false;
try {
final Collection transactionsBeforeRequest =
getTransactions();
for (Transaction transaction : transactionsBeforeRequest) {
if (transaction.getStatus() == Status.STATUS_ACTIVE) {
hasActiveTransaction = true;
break;
}
}
} catch (Exception ex) {
//no-op
}
getNext().invoke(request, response);
if (!hasActiveTransaction) {
try {
final Collection transactionsAfterRequest =
getTransactions();
for (Transaction transaction : transactionsAfterRequest) {
if (transaction.getStatus() == Status.STATUS_ACTIVE) {
logger.log(Level.SEVERE, "Found active transaction: "
+ request.getRequestURI()
+ "?"
+ request.getQueryString()
);
}
}
} catch (Exception ex) {
logger.log(Level.SEVERE, "Failed to determine thread local
transaction status.", ex);
}
}
}
Collection getTransactions() throws NoSuchFieldException,
IllegalAccessException {
final Field threadLocalsField =
Thread.class.getDeclaredField("threadLocals");
threadLocalsField.setAccessible(true);
final Object threadLocals =
threadLocalsField.get(Thread.currentThread());
final Field tableField =
threadLocals.getClass().getDeclaredField("table");
tableField.setAccessible(true);
final Object table = tableField.get(threadLocals);
final Collection transactions = new LinkedList<>();
for (int i = 0; i < Array.getLength(table); i++) {
final Object entry = Array.get(table, i);
if (null != entry) {
final Field valueField =
entry.getClass().getDeclaredField("value");
valueField.setAccessible(true);
final Object value = valueField.get(entry);
if (value instanceof Transaction) {
transactions.add((Transaction) value);
}
}
}
return transactions;
}
{code}
PS: in addition to the issue above, the
org.apache.openejb.cdi.transactional.InterceptorBase must not wrap the
exception specified in the "donotRollbackOn" attribute inside
TransactionalException
was:
@Transactional CDI bean methods annotated with
@Transactional(dontRollbackOn = SomeException.class) do not commit the
transaction at the end of the request/response cycle when the SomeException
exception is thrown. As a result the thread local transaction object is
preserved across requests which makes unrelated requests to fail with "Nested
transactions are not supported".
Sample application that reproduces the issue is attached to the ticket.
Sample valve that can be used to demonstrate the issue:
{code}
public final class LeakedTransactionDetectionValve extends ValveBase {
private static final Logger logger =
Logger.getLogger(LeakedTransactionDetectionValve.class.getName());
@Override
public void invoke(Request request, Response response) throws IOException,
ServletException {
boolean hasActiveTransaction = false;
try {
final Collection transactionsBeforeRequest =
getTransactions();
for (Transaction transaction : transactionsBeforeRequest) {
if (transaction.getStatus() == Status.STATUS_ACTIVE) {
hasActiveTransaction = true;
break;
}
}
} catch (Exception ex) {
//no-op
}
getNext().invoke(request, response);
if
[jira] [Created] (TOMEE-2043) Thread local transactions are left open across requests
Svetlin Zarev created TOMEE-2043:
Summary: Thread local transactions are left open across requests
Key: TOMEE-2043
URL: https://issues.apache.org/jira/browse/TOMEE-2043
Project: TomEE
Issue Type: Bug
Components: TomEE Core Server
Affects Versions: 7.0.3
Reporter: Svetlin Zarev
Attachments: sample.zip
@Transactional CDI bean methods annotated with
@Transactional(dontRollbackOn = SomeException.class) do not commit the
transaction at the end of the request/response cycle when the SomeException
exception is thrown. As a result the thread local transaction object is
preserved across requests which makes unrelated requests to fail with "Nested
transactions are not supported".
Sample application that reproduces the issue is attached to the ticket.
Sample valve that can be used to demonstrate the issue:
{code}
public final class LeakedTransactionDetectionValve extends ValveBase {
private static final Logger logger =
Logger.getLogger(LeakedTransactionDetectionValve.class.getName());
@Override
public void invoke(Request request, Response response) throws IOException,
ServletException {
boolean hasActiveTransaction = false;
try {
final Collection transactionsBeforeRequest =
getTransactions();
for (Transaction transaction : transactionsBeforeRequest) {
if (transaction.getStatus() == Status.STATUS_ACTIVE) {
hasActiveTransaction = true;
break;
}
}
} catch (Exception ex) {
//no-op
}
getNext().invoke(request, response);
if (!hasActiveTransaction) {
try {
final Collection transactionsAfterRequest =
getTransactions();
for (Transaction transaction : transactionsAfterRequest) {
if (transaction.getStatus() == Status.STATUS_ACTIVE) {
logger.log(Level.SEVERE, "Found active transaction: "
+ request.getRequestURI()
+ "?"
+ request.getQueryString()
);
}
}
} catch (Exception ex) {
logger.log(Level.SEVERE, "Failed to determine thread local
transaction status.", ex);
}
}
}
Collection getTransactions() throws NoSuchFieldException,
IllegalAccessException {
final Field threadLocalsField =
Thread.class.getDeclaredField("threadLocals");
threadLocalsField.setAccessible(true);
final Object threadLocals =
threadLocalsField.get(Thread.currentThread());
final Field tableField =
threadLocals.getClass().getDeclaredField("table");
tableField.setAccessible(true);
final Object table = tableField.get(threadLocals);
final Collection transactions = new LinkedList<>();
for (int i = 0; i < Array.getLength(table); i++) {
final Object entry = Array.get(table, i);
if (null != entry) {
final Field valueField =
entry.getClass().getDeclaredField("value");
valueField.setAccessible(true);
final Object value = valueField.get(entry);
if (value instanceof Transaction) {
transactions.add((Transaction) value);
}
}
}
return transactions;
}
{code}
PS: in addition to the issue above, the
org.apache.openejb.cdi.transactional.InterceptorBase must not wrap the
exception specified in the "donotRollbackOn" attribute inside
TransactionalException
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (TOMEE-2024) Misleading log entries
[
https://issues.apache.org/jira/browse/TOMEE-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924305#comment-15924305
]
Svetlin Zarev edited comment on TOMEE-2024 at 3/14/17 2:29 PM:
---
I have created the JTA and NON-JTA data-sources, but it says that my JTA ds
is not JTA and and then desides to create a new default ds. The same for the
Non-JTA datasource. So instead of using my database I ended up using the
in-memory HSQL db.
It printed something like adjusting from jdbc/MyDataSource to
"Default JDBC Something"
was (Author: svetlinzarev):
I have created the JTA and NON-JTA data-sources, but it says that my JTA ds
is not JTA and and then desides to create a new default ds. The same for the
Non-JTA datasource. So instead of using my database I end up using the
in-memory HSQL db.
It printed something like adjusting from jdbc/MyDataSource to
"Default JDBC Something"
> Misleading log entries
> --
>
> Key: TOMEE-2024
> URL: https://issues.apache.org/jira/browse/TOMEE-2024
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.3, 7.0.4
>Reporter: Svetlin Zarev
>Priority: Minor
>
> Assembler:1420-1454:
> {code}
> final String jtaWithJavaAndSlash =
> replaceJavaAndSlash(unit.getJtaDataSource());
> for (final String potentialName : asList(prefix +
> jtaWithJavaAndSlash, originalJtaDataSource, jtaWithJavaAndSlash)) {
> if(potentialName == null) {
> // If unit.getJtaDataSource() is null, one of the
> potentialName is also null.
> continue;
> }
> final ResourceInfo jtaInfo =
> configFactory.getResourceInfo(potentialName);
> if (jtaInfo != null) {
> if
> (!"false".equalsIgnoreCase(jtaInfo.properties.getProperty("JtaManaged")) //
> don't test true since it can be missing
> && (jtaInfo.types.contains("DataSource") ||
> jtaInfo.types.contains(DataSource.class.getName( {
> jtaDataSourceId = jtaInfo.id;
> break;
> } else {
> ->logger.warning("Found matching datasource: " +
> jtaInfo.id + " but this one is not a JTA datasource");
> }
> }
> }
> final String nonJtaWithJavaAndSlash =
> replaceJavaAndSlash(unit.getNonJtaDataSource());
> for (final String potentialName : asList(prefix +
> nonJtaWithJavaAndSlash, originalNonJtaDataSource, nonJtaWithJavaAndSlash)) {
> if(potentialName == null) {
> // If unit.getNonJtaDataSource() is null, one of the
> potentialName is also null.
> continue;
> }
> final ResourceInfo info =
> configFactory.getResourceInfo(potentialName);
> if (info != null) {
> if
> (!"true".equalsIgnoreCase(info.properties.getProperty("JtaManaged"))
> && (info.types.contains("DataSource") ||
> info.types.contains(DataSource.class.getName( {
> nonJtaDataSourceId = info.id;
> break;
> } else {
> ->logger.warning("Found matching datasource: " +
> info.id + " but this one is a JTA datasource");
> }
> }
> }
> {code}
> The two warnings are very misleading, because it prints that my JTA
> data-source is NON JTA one, and my non-jta is jta data-source when my service
> provider does not have "javax.sql.DataSource" in the "types" property.
> Also IMO when I explicitly set the service provider it should not matter what
> "types" it has in the service-jar.xml.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (TOMEE-2024) Misleading log entries
[
https://issues.apache.org/jira/browse/TOMEE-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924305#comment-15924305
]
Svetlin Zarev edited comment on TOMEE-2024 at 3/14/17 2:26 PM:
---
I have created the JTA and NON-JTA data-sources, but it says that my JTA ds
is not JTA and and then desides to create a new default ds. The same for the
Non-JTA datasource. So instead of using my database I end up using the
in-memory HSQL db.
It printed something like adjusting from jdbc/MyDataSource to
"Default JDBC Something"
was (Author: svetlinzarev):
I have created the JTA and NON-JTA data-sources, but it says that my JTA ds
is not JTA and and then desides to create a new default ds. The same for the
Non-JTA datasource. So instead of using my database I end up using the
in-memory HSQL db.
> Misleading log entries
> --
>
> Key: TOMEE-2024
> URL: https://issues.apache.org/jira/browse/TOMEE-2024
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 7.0.3, 7.0.4
>Reporter: Svetlin Zarev
>Priority: Minor
>
> Assembler:1420-1454:
> {code}
> final String jtaWithJavaAndSlash =
> replaceJavaAndSlash(unit.getJtaDataSource());
> for (final String potentialName : asList(prefix +
> jtaWithJavaAndSlash, originalJtaDataSource, jtaWithJavaAndSlash)) {
> if(potentialName == null) {
> // If unit.getJtaDataSource() is null, one of the
> potentialName is also null.
> continue;
> }
> final ResourceInfo jtaInfo =
> configFactory.getResourceInfo(potentialName);
> if (jtaInfo != null) {
> if
> (!"false".equalsIgnoreCase(jtaInfo.properties.getProperty("JtaManaged")) //
> don't test true since it can be missing
> && (jtaInfo.types.contains("DataSource") ||
> jtaInfo.types.contains(DataSource.class.getName( {
> jtaDataSourceId = jtaInfo.id;
> break;
> } else {
> ->logger.warning("Found matching datasource: " +
> jtaInfo.id + " but this one is not a JTA datasource");
> }
> }
> }
> final String nonJtaWithJavaAndSlash =
> replaceJavaAndSlash(unit.getNonJtaDataSource());
> for (final String potentialName : asList(prefix +
> nonJtaWithJavaAndSlash, originalNonJtaDataSource, nonJtaWithJavaAndSlash)) {
> if(potentialName == null) {
> // If unit.getNonJtaDataSource() is null, one of the
> potentialName is also null.
> continue;
> }
> final ResourceInfo info =
> configFactory.getResourceInfo(potentialName);
> if (info != null) {
> if
> (!"true".equalsIgnoreCase(info.properties.getProperty("JtaManaged"))
> && (info.types.contains("DataSource") ||
> info.types.contains(DataSource.class.getName( {
> nonJtaDataSourceId = info.id;
> break;
> } else {
> ->logger.warning("Found matching datasource: " +
> info.id + " but this one is a JTA datasource");
> }
> }
> }
> {code}
> The two warnings are very misleading, because it prints that my JTA
> data-source is NON JTA one, and my non-jta is jta data-source when my service
> provider does not have "javax.sql.DataSource" in the "types" property.
> Also IMO when I explicitly set the service provider it should not matter what
> "types" it has in the service-jar.xml.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
