[jira] Updated: (GERONIMO-3655) Invalid MdbInstanceFactory behaviour
[ https://issues.apache.org/jira/browse/GERONIMO-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Akimov updated GERONIMO-3655: Attachment: badmdb.zip Sample application to reproduce the prolem Invalid MdbInstanceFactory behaviour Key: GERONIMO-3655 URL: https://issues.apache.org/jira/browse/GERONIMO-3655 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.1, 2.0.2 Environment: Microsoft Windows XP, Sun Java 1.5.0_10, Apache Geronimo 2.0.1 Reporter: Alexei Akimov Attachments: badmdb.zip org.apache.openejb.core.mdb.MdbInstanceFactory class pass invalid ThreadContext instance to ThreadContext.exit method at line 263 of its constructBean method. This brokes stack-like usage of ThreadContext objects and leads to problems during lazy initialization of ejb components when they called for the first time from the web tier. In particular ClassCastException is thrown in org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.before() at line 49, because ConnectorInstanceContextImpl instance is returned instead of SharedConnectorInstanceContext instance. This error results in that org.apache.geronimo.tomcat.listener.DispatchListener.beforeDispatch method does not put any data into the current context stack so when the afterDispatch method is called the current context stack throws java.util.EmptyStackException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3655) Invalid MdbInstanceFactory behaviour
Invalid MdbInstanceFactory behaviour Key: GERONIMO-3655 URL: https://issues.apache.org/jira/browse/GERONIMO-3655 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.0.2, 2.0.1 Environment: Microsoft Windows XP, Sun Java 1.5.0_10, Apache Geronimo 2.0.1 Reporter: Alexei Akimov org.apache.openejb.core.mdb.MdbInstanceFactory class pass invalid ThreadContext instance to ThreadContext.exit method at line 263 of its constructBean method. This brokes stack-like usage of ThreadContext objects and leads to problems during lazy initialization of ejb components when they called for the first time from the web tier. In particular ClassCastException is thrown in org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.before() at line 49, because ConnectorInstanceContextImpl instance is returned instead of SharedConnectorInstanceContext instance. This error results in that org.apache.geronimo.tomcat.listener.DispatchListener.beforeDispatch method does not put any data into the current context stack so when the afterDispatch method is called the current context stack throws java.util.EmptyStackException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-215) Does not work right-clik's option Remove to remove project from Server (Servers View)
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537592
]
Alexei Akimov commented on GERONIMODEVTOOLS-215:
Hi,
the problem mentioned above is caused by fuzzy contract of modifyModules method
in org.eclipse.wst.server.core.IServerWorkingCopy. The first two parameters of
it are arrays of IModule and it is not clear if one of the arrays may be null.
Anyway, when you remove project from the server, then an instance of
org.eclipse.wst.server.ui.internal.view.servers.RemoveModuleAction is invoked:
...
IServerWorkingCopy wc = server.createWorkingCopy();
wc.modifyModules(null, new IModule[] { module }, null);
server = wc.save(true, null);
...
The call is delegated for several times and finally canModyfyModules method of
org.apache.geronimo.st.core;GeronimoServerDelegate is invoked
public IStatus canModifyModules(IModule[] add, IModule[] remove) {
for (int i = 0; i add.length; i++) {
IModule module = add[i];
if (module.getProject() != null) {
IStatus status =
FacetUtil.verifyFacets(module.getProject(), getServer());
if (status != null !status.isOK())
return status;
}
}
return Status.OK_STATUS;
}
It is clear that the first line of implementation will resut in
NullPointerException which later will cause CoreException and invalid status of
the operation.
Does not work right-clik's option Remove to remove project from Server
(Servers View)
-
Key: GERONIMODEVTOOLS-215
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-215
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 2.0.0
Reporter: Tomasz Mazan
Assignee: Tim McConnell
Hi Tomasz, Sorry to be so dense but I'm missing something obvious. Are you
able/willing to provide the artifacts that is causing the failure for you ??
If not, are these the correct steps that is causing the failure (so I can try
to reproduce) ??
1. Deploy your first ejb.jar
2. Deploy your ear, which contains other ejb.jar files
3. Then I assume you're attempting to undeploy the ear that was deployed in
Step 2 ??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-215) Does not work right-clik's option Remove to remove project from Server (Servers View)
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537592
]
akimov edited comment on GERONIMODEVTOOLS-215 at 10/25/07 6:23 AM:
--
Hi,
the problem mentioned above is caused by fuzzy contract of modifyModules method
in org.eclipse.wst.server.core.IServerWorkingCopy. The first two parameters of
it are arrays of IModule and it is not clear if one of the arrays may be null.
Anyway, when you remove project from the server, then an instance of
org.eclipse.wst.server.ui.internal.view.servers.RemoveModuleAction is invoked:
...
IServerWorkingCopy wc = server.createWorkingCopy();
wc.modifyModules(null, new IModule[] { module }, null);
server = wc.save(true, null);
...
The call is delegated for several times and finally canModyfyModules method of
org.apache.geronimo.st.core.GeronimoServerDelegate is invoked
public IStatus canModifyModules(IModule[] add, IModule[] remove) {
for (int i = 0; i add.length; i++) {
IModule module = add[i];
if (module.getProject() != null) {
IStatus status =
FacetUtil.verifyFacets(module.getProject(), getServer());
if (status != null !status.isOK())
return status;
}
}
return Status.OK_STATUS;
}
It is clear that the first line of implementation will resut in
NullPointerException which later will cause CoreException and invalid status of
the operation.
was (Author: akimov):
Hi,
the problem mentioned above is caused by fuzzy contract of modifyModules method
in org.eclipse.wst.server.core.IServerWorkingCopy. The first two parameters of
it are arrays of IModule and it is not clear if one of the arrays may be null.
Anyway, when you remove project from the server, then an instance of
org.eclipse.wst.server.ui.internal.view.servers.RemoveModuleAction is invoked:
...
IServerWorkingCopy wc = server.createWorkingCopy();
wc.modifyModules(null, new IModule[] { module }, null);
server = wc.save(true, null);
...
The call is delegated for several times and finally canModyfyModules method of
org.apache.geronimo.st.core;GeronimoServerDelegate is invoked
public IStatus canModifyModules(IModule[] add, IModule[] remove) {
for (int i = 0; i add.length; i++) {
IModule module = add[i];
if (module.getProject() != null) {
IStatus status =
FacetUtil.verifyFacets(module.getProject(), getServer());
if (status != null !status.isOK())
return status;
}
}
return Status.OK_STATUS;
}
It is clear that the first line of implementation will resut in
NullPointerException which later will cause CoreException and invalid status of
the operation.
Does not work right-clik's option Remove to remove project from Server
(Servers View)
-
Key: GERONIMODEVTOOLS-215
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-215
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 2.0.0
Reporter: Tomasz Mazan
Assignee: Tim McConnell
Hi Tomasz, Sorry to be so dense but I'm missing something obvious. Are you
able/willing to provide the artifacts that is causing the failure for you ??
If not, are these the correct steps that is causing the failure (so I can try
to reproduce) ??
1. Deploy your first ejb.jar
2. Deploy your ear, which contains other ejb.jar files
3. Then I assume you're attempting to undeploy the ear that was deployed in
Step 2 ??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-215) Does not work right-clik's option Remove to remove project from Server (Servers View)
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537592
]
akimov edited comment on GERONIMODEVTOOLS-215 at 10/25/07 6:24 AM:
--
Hi,
the problem mentioned above is caused by fuzzy contract of modifyModules method
in org.eclipse.wst.server.core.IServerWorkingCopy. The first two parameters of
it are arrays of IModule and it is not clear if one of the arrays may be null.
Anyway, when you remove project from the server, then an instance of
org.eclipse.wst.server.ui.internal.view.servers.RemoveModuleAction is invoked:
...
IServerWorkingCopy wc = server.createWorkingCopy();
wc.modifyModules(null, new IModule[] { module }, null);
server = wc.save(true, null);
...
The call is delegated for several times and finally canModyfyModules method of
org.apache.geronimo.st.core.GeronimoServerDelegate is invoked
public IStatus canModifyModules(IModule[] add, IModule[] remove) {
for (int i = 0; i add.length; i++) {
IModule module = add[i];
if (module.getProject() != null) {
IStatus status =
FacetUtil.verifyFacets(module.getProject(), getServer());
if (status != null !status.isOK())
return status;
}
}
return Status.OK_STATUS;
}
It is clear that the first line of implementation will result in
NullPointerException which later will cause CoreException and invalid status of
the operation.
was (Author: akimov):
Hi,
the problem mentioned above is caused by fuzzy contract of modifyModules method
in org.eclipse.wst.server.core.IServerWorkingCopy. The first two parameters of
it are arrays of IModule and it is not clear if one of the arrays may be null.
Anyway, when you remove project from the server, then an instance of
org.eclipse.wst.server.ui.internal.view.servers.RemoveModuleAction is invoked:
...
IServerWorkingCopy wc = server.createWorkingCopy();
wc.modifyModules(null, new IModule[] { module }, null);
server = wc.save(true, null);
...
The call is delegated for several times and finally canModyfyModules method of
org.apache.geronimo.st.core.GeronimoServerDelegate is invoked
public IStatus canModifyModules(IModule[] add, IModule[] remove) {
for (int i = 0; i add.length; i++) {
IModule module = add[i];
if (module.getProject() != null) {
IStatus status =
FacetUtil.verifyFacets(module.getProject(), getServer());
if (status != null !status.isOK())
return status;
}
}
return Status.OK_STATUS;
}
It is clear that the first line of implementation will resut in
NullPointerException which later will cause CoreException and invalid status of
the operation.
Does not work right-clik's option Remove to remove project from Server
(Servers View)
-
Key: GERONIMODEVTOOLS-215
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-215
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 2.0.0
Reporter: Tomasz Mazan
Assignee: Tim McConnell
Hi Tomasz, Sorry to be so dense but I'm missing something obvious. Are you
able/willing to provide the artifacts that is causing the failure for you ??
If not, are these the correct steps that is causing the failure (so I can try
to reproduce) ??
1. Deploy your first ejb.jar
2. Deploy your ear, which contains other ejb.jar files
3. Then I assume you're attempting to undeploy the ear that was deployed in
Step 2 ??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
