[jira] Commented: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[ https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484874 ] Rakesh Midha commented on GERONIMO-3020: But the question still remain, do we want to register DFwK or impl in DFwK or not. As Frank suggested before, pointing to the comments of rev 519908. Unable to deploy a web app to current trunk build of geronimo (rev 522077) -- Key: GERONIMO-3020 URL: https://issues.apache.org/jira/browse/GERONIMO-3020 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M5 Environment: Linux - Java 1.5.0_08 Reporter: Jay D. McHugh Assigned To: Gianny Damour Priority: Blocker Fix For: 2.0-M4 Attachments: GERONIMO-3020-3.patch, J3020.patch, J3020_opt.patch, JIRA3020_useDFWithKernel.patch Trying to deploy a web app from the web based admin console causes a servlet exception. Deploying the same web app from the command line is successful. (ie: java -jar bin/deployer.jar --user system --password manager deploy simple.war) You should be able to duplicate by trying to deploy the simple.war file from geronimo-2786. Here is the stack trace: 15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment threw exception javax.servlet.ServletException at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) 15:12:20,344 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet.
[jira] Commented: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[ https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484438 ] Rakesh Midha commented on GERONIMO-3020: Thanks for pointing, I didn;t see this comment, but I think registering deployment factory is required if we want to use DeploymentFactoryWithKernel. So now we have a case in web console new deploy, where we want DeploymentFactoryWithKernel to register DeploymentFactory and case plugin install where we don't want it to register. Let me try to implement something and get back. Thanks Rakesh Unable to deploy a web app to current trunk build of geronimo (rev 522077) -- Key: GERONIMO-3020 URL: https://issues.apache.org/jira/browse/GERONIMO-3020 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M5 Environment: Linux - Java 1.5.0_08 Reporter: Jay D. McHugh Assigned To: Gianny Damour Priority: Blocker Attachments: J3020.patch, J3020_opt.patch Trying to deploy a web app from the web based admin console causes a servlet exception. Deploying the same web app from the command line is successful. (ie: java -jar bin/deployer.jar --user system --password manager deploy simple.war) You should be able to duplicate by trying to deploy the simple.war file from geronimo-2786. Here is the stack trace: 15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment threw exception javax.servlet.ServletException at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
[jira] Commented: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[
https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484440
]
Rakesh Midha commented on GERONIMO-3020:
I didn't go into the details of why plugins's won't like us to register
DeploymentFactory. May be Gianny can help me understand that part.
If we don;t want register DeploymentFactory, and still use it in
DeploymentPortlet, Another way could be to use
org.apache.geronimo.kernel.Kernel kernel =
org.apache.geronimo.kernel.KernelRegistry.getSingleKernel();
DeploymentFactory factory = new DeploymentFactoryWithKernel(kernel);
FileInputStream fis = null;
try {
DeploymentManager mgr =
factory.getDeploymentManager(deployer:geronimo:inVM, null, null);
.
instead of
DeploymentFactoryManager dfm = DeploymentFactoryManager.getInstance();
FileInputStream fis = null;
try {
DeploymentManager mgr =
dfm.getDeploymentManager(deployer:geronimo:inVM, null, null);
in DeploymentPortlet.java
Let me test and think of any side effects it may have. (One I can think of is
direct use of kernel in DeploymentPortlet.). I will put a patch with this code
changes, but only after some thinking and test.
Unable to deploy a web app to current trunk build of geronimo (rev 522077)
--
Key: GERONIMO-3020
URL: https://issues.apache.org/jira/browse/GERONIMO-3020
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0-M5
Environment: Linux - Java 1.5.0_08
Reporter: Jay D. McHugh
Assigned To: Gianny Damour
Priority: Blocker
Attachments: J3020.patch, J3020_opt.patch
Trying to deploy a web app from the web based admin console causes a servlet
exception.
Deploying the same web app from the command line is successful.
(ie: java -jar bin/deployer.jar --user system --password manager deploy
simple.war)
You should be able to duplicate by trying to deploy the simple.war file from
geronimo-2786.
Here is the stack trace:
15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment
threw exception
javax.servlet.ServletException
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260)
at
org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
at
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
[jira] Updated: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[ https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-3020: --- Attachment: JIRA3020_useDFWithKernel.patch This JIRA3020_useDFWithKernel.patch is a patch if we want to use DeploymentFactoryWithKernel as discussed in my last comment. I did not test plugin scenario as I am not aware of it. From my initial test this works fine. Unable to deploy a web app to current trunk build of geronimo (rev 522077) -- Key: GERONIMO-3020 URL: https://issues.apache.org/jira/browse/GERONIMO-3020 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M5 Environment: Linux - Java 1.5.0_08 Reporter: Jay D. McHugh Assigned To: Gianny Damour Priority: Blocker Attachments: J3020.patch, J3020_opt.patch, JIRA3020_useDFWithKernel.patch Trying to deploy a web app from the web based admin console causes a servlet exception. Deploying the same web app from the command line is successful. (ie: java -jar bin/deployer.jar --user system --password manager deploy simple.war) You should be able to duplicate by trying to deploy the simple.war file from geronimo-2786. Here is the stack trace: 15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment threw exception javax.servlet.ServletException at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) 15:12:20,344 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error
[jira] Updated: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[
https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rakesh Midha updated GERONIMO-3020:
---
Attachment: J3020.patch
Frank, you are right about DeploymentFactoryWithKernel rev 519908, I also came
to same conclusion last night.
I added
static {
DeploymentFactoryManager manager =
DeploymentFactoryManager.getInstance();
manager.registerDeploymentFactory(new DeploymentFactoryImpl());
}
to BaseDeploymentFactory.java and did some testing and things worked fine.
Attached is the patch for review and commit.
(Sorry I didn't see that this problem is assigned, I think it was not when I
last disconnected from my network, I was working offline)
Thanks
Rakesh
Unable to deploy a web app to current trunk build of geronimo (rev 522077)
--
Key: GERONIMO-3020
URL: https://issues.apache.org/jira/browse/GERONIMO-3020
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0-M5
Environment: Linux - Java 1.5.0_08
Reporter: Jay D. McHugh
Assigned To: Gianny Damour
Attachments: J3020.patch
Trying to deploy a web app from the web based admin console causes a servlet
exception.
Deploying the same web app from the command line is successful.
(ie: java -jar bin/deployer.jar --user system --password manager deploy
simple.war)
You should be able to duplicate by trying to deploy the simple.war file from
geronimo-2786.
Here is the stack trace:
15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment
threw exception
javax.servlet.ServletException
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260)
at
org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
at
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
[jira] Updated: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[ https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-3020: --- Patch Info: [Patch Available] Unable to deploy a web app to current trunk build of geronimo (rev 522077) -- Key: GERONIMO-3020 URL: https://issues.apache.org/jira/browse/GERONIMO-3020 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M5 Environment: Linux - Java 1.5.0_08 Reporter: Jay D. McHugh Assigned To: Gianny Damour Attachments: J3020.patch Trying to deploy a web app from the web based admin console causes a servlet exception. Deploying the same web app from the command line is successful. (ie: java -jar bin/deployer.jar --user system --password manager deploy simple.war) You should be able to duplicate by trying to deploy the simple.war file from geronimo-2786. Here is the stack trace: 15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment threw exception javax.servlet.ServletException at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) 15:12:20,344 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException at org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:196) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at
[jira] Updated: (GERONIMO-3020) Unable to deploy a web app to current trunk build of geronimo (rev 522077)
[ https://issues.apache.org/jira/browse/GERONIMO-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-3020: --- Attachment: J3020_opt.patch To be used optionally, to remove static deploymentfactory registration code from DeploymentFactoryImpl.java. Another approach could be to keep code in deploymentfactoryimpl and add code only in DeploymentFactoryWithKernel.java Unable to deploy a web app to current trunk build of geronimo (rev 522077) -- Key: GERONIMO-3020 URL: https://issues.apache.org/jira/browse/GERONIMO-3020 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M5 Environment: Linux - Java 1.5.0_08 Reporter: Jay D. McHugh Assigned To: Gianny Damour Attachments: J3020.patch, J3020_opt.patch Trying to deploy a web app from the web based admin console causes a servlet exception. Deploying the same web app from the command line is successful. (ie: java -jar bin/deployer.jar --user system --password manager deploy simple.war) You should be able to duplicate by trying to deploy the simple.war file from geronimo-2786. Here is the stack trace: 15:12:20,342 ERROR [[Deployment]] Servlet.service() for servlet Deployment threw exception javax.servlet.ServletException at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:260) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:324) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) 15:12:20,344 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException at
[jira] Commented: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484322 ] Rakesh Midha commented on GERONIMO-2661: Thanks Christopher I can start my work on 2660 now. I hope that too makes sense. Thanks Rakesh Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0-M5 Environment: Any Reporter: Rakesh Midha Assigned To: Christopher M. Cardona Priority: Minor Fix For: 2.0-M5 Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1945) Console's web application list does not show WARs that are deployed inside EARs
[ https://issues.apache.org/jira/browse/GERONIMO-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-1945: --- Attachment: jira1945.patch Made changes in connector builder and openejb builder to add submodules as a children's rather than direct modules. This will make sure that getchildren() on ear will return all the childs, earlier it was returning only web children's. The console view now shows all the modules which are part of ear, all the commands corresponding to these listings are actually applied to parent ear module. The web URL link is only shown if application is in running state. All the places where getChildrens() or getChildrenConfiguration was used requires changes. One such case which was changed is dependencyViewer. Console's web application list does not show WARs that are deployed inside EARs --- Key: GERONIMO-1945 URL: https://issues.apache.org/jira/browse/GERONIMO-1945 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Erin Mulder Assigned To: Rakesh Midha Fix For: Wish List Attachments: jira1945.patch In the console, click on Applications - Web App WARs. The resulting list of web applications does not include any web application that is packaged as part of an EAR. (The list is populated inside ConfigManagerPortlet.doView) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1945) Console's web application list does not show WARs that are deployed inside EARs
[ https://issues.apache.org/jira/browse/GERONIMO-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-1945: --- Patch Info: [Patch Available] Affects Version/s: 2.0-M3 Fix Version/s: (was: Wish List) 2.0-M1 Assignee: (was: Rakesh Midha) Marking patch available, unassigning so that someone can review and comment/commit. Console's web application list does not show WARs that are deployed inside EARs --- Key: GERONIMO-1945 URL: https://issues.apache.org/jira/browse/GERONIMO-1945 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 2.0-M3 Reporter: Erin Mulder Fix For: 2.0-M1 Attachments: jira1945.patch In the console, click on Applications - Web App WARs. The resulting list of web applications does not include any web application that is packaged as part of an EAR. (The list is populated inside ConfigManagerPortlet.doView) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1945) Console's web application list does not show WARs that are deployed inside EARs
[ https://issues.apache.org/jira/browse/GERONIMO-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-1945: --- Affects Version/s: (was: 2.0-M3) 2.0-M1 Console's web application list does not show WARs that are deployed inside EARs --- Key: GERONIMO-1945 URL: https://issues.apache.org/jira/browse/GERONIMO-1945 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 2.0-M1 Reporter: Erin Mulder Fix For: 2.0-M1 Attachments: jira1945.patch In the console, click on Applications - Web App WARs. The resulting list of web applications does not include any web application that is packaged as part of an EAR. (The list is populated inside ConfigManagerPortlet.doView) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-1945) Console's web application list does not show WARs that are deployed inside EARs
[ https://issues.apache.org/jira/browse/GERONIMO-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha reassigned GERONIMO-1945: -- Assignee: Rakesh Midha Console's web application list does not show WARs that are deployed inside EARs --- Key: GERONIMO-1945 URL: https://issues.apache.org/jira/browse/GERONIMO-1945 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Erin Mulder Assigned To: Rakesh Midha Fix For: Wish List In the console, click on Applications - Web App WARs. The resulting list of web applications does not include any web application that is packaged as part of an EAR. (The list is populated inside ConfigManagerPortlet.doView) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2854) Inverse Classloader view
[ https://issues.apache.org/jira/browse/GERONIMO-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha reassigned GERONIMO-2854: -- Assignee: Rakesh Midha Inverse Classloader view Key: GERONIMO-2854 URL: https://issues.apache.org/jira/browse/GERONIMO-2854 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M2 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0-M2 Attachments: jira2854.patch Inverse classloader view to navigate through classloader's parent which will be child nodes in dojo tree. As discussed in thread http://www.mail-archive.com/dev@geronimo.apache.org/msg41904.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2854) Inverse Classloader view
[ https://issues.apache.org/jira/browse/GERONIMO-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2854: --- Attachment: jira2854sort.patch List presented in sorted asending order for all the three views (Classloader, JNDI and dependency). Changing StringTree to support comparison. Inverse Classloader view Key: GERONIMO-2854 URL: https://issues.apache.org/jira/browse/GERONIMO-2854 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M2 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0-M2 Attachments: jira2854.patch, jira2854sort.patch Inverse classloader view to navigate through classloader's parent which will be child nodes in dojo tree. As discussed in thread http://www.mail-archive.com/dev@geronimo.apache.org/msg41904.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2854) Inverse Classloader view
[ https://issues.apache.org/jira/browse/GERONIMO-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2854: --- Assignee: (was: Rakesh Midha) Patch provided for sorted list. Unassigning, please review and commit. Thanks Rakesh Inverse Classloader view Key: GERONIMO-2854 URL: https://issues.apache.org/jira/browse/GERONIMO-2854 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M2 Environment: Any Reporter: Rakesh Midha Fix For: 2.0-M2 Attachments: jira2854.patch, jira2854sort.patch Inverse classloader view to navigate through classloader's parent which will be child nodes in dojo tree. As discussed in thread http://www.mail-archive.com/dev@geronimo.apache.org/msg41904.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2676) Web Application without required jars throws NullPointer
[ https://issues.apache.org/jira/browse/GERONIMO-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476966 ] Rakesh Midha commented on GERONIMO-2676: Can someone or KK, please confirm the status so that we can close or recify the problem. Thanks Rakesh Web Application without required jars throws NullPointer Key: GERONIMO-2676 URL: https://issues.apache.org/jira/browse/GERONIMO-2676 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0 Reporter: Krishnakumar B I have tried deploying applications like ActiveBPEL and MyFaces examples on geronimo. If i dont add the required jars for these application's to run i get a NullPointerException. The service J2EEApplication=null,j2eeType=WebModule,name=default/myfaces-examp le-simple-1.1.5-SNAPSHOT/1166707464231/war did not start because the doStart met hod threw an exception. java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:396) at org.apache.naming.resources.DirContextURLStreamHandler.bind(DirContex tURLStreamHandler.java:234) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppCo ntext.java:477) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:984) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:543) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:378) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:527) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:508) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$Enhan cerByCGLIB$$b42bfad1.startConfiguration(generated) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCom mand.java:67) at java.lang.Thread.run(Thread.java:595) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:407) ... 14 more A more user friendly exception will help the user to add the required jars. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-807) Better handling for system log viewer portlet render requests
[ https://issues.apache.org/jira/browse/GERONIMO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha reassigned GERONIMO-807: - Assignee: Rakesh Midha Quite longLet me try to end this night Better handling for system log viewer portlet render requests - Key: GERONIMO-807 URL: https://issues.apache.org/jira/browse/GERONIMO-807 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, usability Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List If you interact with a different portal on the log page, the system log viewer portlet reverts to its default filter settings. It should instead default to the same values used previously (if there are previous search criteria and if none of the criteria were submitted in the request). See LogViewerPortlet.java:73 or so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha closed GERONIMO-2742. -- Resolution: Invalid Closing JIRA as per last comment and previous discussion. Conclusion: 1. To use sharedlib in offline mode it need to be added in offline list 2. sharedlib working fine. 3. Its expected that exploded jar file will work in repository, if it doesn't it will be handled in different JIRA Deployer cannot access libaries in shared/lib and shared/classes Key: GERONIMO-2742 URL: https://issues.apache.org/jira/browse/GERONIMO-2742 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: Windows XP, Geronimo 1.2-beta Reporter: Aman Nanner Attachments: sharedlib-2.0.zip, sharedlib.zip, testing.ear.zip It seems that when running the deployer to deploy my EAR file, the classloaders during deployment cannot access the shared/lib and shared/classes directory. My app has dependencies on libraries that are stored in both shared/classes and shared/lib. Because these libraries cannot be found, the deployment fails. Neither regular deployment nor hot deployment works. My EAR file used to hot deploy properly in Geronimo 1.1.1 (I never used the regular deployer in 1.1.1, so I don't know if that would have worked too). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-807) Better handling for system log viewer portlet render requests
[ https://issues.apache.org/jira/browse/GERONIMO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-807: -- Attachment: jira807.patch Attached is the patch to take care of not only just default values, but also take care of 1. Remember the last values in case of refresh and reload in same session 2. Take care of invalid values 3. Solve the above problem for Log Manager, Web Access logger and derby logger Better handling for system log viewer portlet render requests - Key: GERONIMO-807 URL: https://issues.apache.org/jira/browse/GERONIMO-807 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, usability Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: jira807.patch If you interact with a different portal on the log page, the system log viewer portlet reverts to its default filter settings. It should instead default to the same values used previously (if there are previous search criteria and if none of the criteria were submitted in the request). See LogViewerPortlet.java:73 or so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-807) Better handling for system log viewer portlet render requests
[ https://issues.apache.org/jira/browse/GERONIMO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-807: -- Patch Info: [Patch Available] Fix Version/s: (was: Wish List) 2.0-M2 Assignee: (was: Rakesh Midha) Unassigning and marking patch available Please review and commit Better handling for system log viewer portlet render requests - Key: GERONIMO-807 URL: https://issues.apache.org/jira/browse/GERONIMO-807 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, usability Affects Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Minor Fix For: 2.0-M2 Attachments: jira807.patch If you interact with a different portal on the log page, the system log viewer portlet reverts to its default filter settings. It should instead default to the same values used previously (if there are previous search criteria and if none of the criteria were submitted in the request). See LogViewerPortlet.java:73 or so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2854) Inverse Classloader view
[ https://issues.apache.org/jira/browse/GERONIMO-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2854: --- Attachment: jira2854.patch Improvement in Classloader view 1. Added Invert Tree button in Classloader View, this button will invert the classloader hirarchy for those who like to view parent classloaders and its classes as a child node to main nodes. 2. In inverted classloader tree, the initial nodes will show all the classloaders 3. Selected node in classloader will be found in inverted node and selected (the first occurance of node will be selected) The patch adds following code --- The first level of tree cannot be links, so code added to make sure of it InverseTree method added to get inverseTree JSP code added to remember last selected node and boolean inverse status Inverse Classloader view Key: GERONIMO-2854 URL: https://issues.apache.org/jira/browse/GERONIMO-2854 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M2 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0-M2 Attachments: jira2854.patch Inverse classloader view to navigate through classloader's parent which will be child nodes in dojo tree. As discussed in thread http://www.mail-archive.com/dev@geronimo.apache.org/msg41904.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2854) Inverse Classloader view
[ https://issues.apache.org/jira/browse/GERONIMO-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2854: --- Description: Inverse classloader view to navigate through classloader's parent which will be child nodes in dojo tree. As discussed in thread http://www.mail-archive.com/dev@geronimo.apache.org/msg41904.html was: Inverse classloader view to navigate through classloader's parent which will be child nodes in dojo tree. As discussed in thread http://www.mail-archive.com/dev@geronimo.apache.org/msg41904.html Patch Info: [Patch Available] Assignee: (was: Rakesh Midha) Unassigning and marking Patch available Please review and commit Inverse Classloader view Key: GERONIMO-2854 URL: https://issues.apache.org/jira/browse/GERONIMO-2854 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0-M2 Environment: Any Reporter: Rakesh Midha Fix For: 2.0-M2 Attachments: jira2854.patch Inverse classloader view to navigate through classloader's parent which will be child nodes in dojo tree. As discussed in thread http://www.mail-archive.com/dev@geronimo.apache.org/msg41904.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474693 ] Rakesh Midha commented on GERONIMO-2742: Hello Aman From what I know and from the simple test I did on repository. I don't think there is any problem in having directory named geronimo-connector-1.2-beta.jar (the name same as jar file), I think you need to add META-INF and manifest.mf files in directory . This directory will be treadted in same way as if it is a jar file. This directory could be a symb link as you said, thought never tried this but i don't see any problem in it. Have you tried doing this, I think you should not face any problem with this. thanks Rakesh Deployer cannot access libaries in shared/lib and shared/classes Key: GERONIMO-2742 URL: https://issues.apache.org/jira/browse/GERONIMO-2742 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: Windows XP, Geronimo 1.2-beta Reporter: Aman Nanner Attachments: sharedlib-2.0.zip, sharedlib.zip, testing.ear.zip It seems that when running the deployer to deploy my EAR file, the classloaders during deployment cannot access the shared/lib and shared/classes directory. My app has dependencies on libraries that are stored in both shared/classes and shared/lib. Because these libraries cannot be found, the deployment fails. Neither regular deployment nor hot deployment works. My EAR file used to hot deploy properly in Geronimo 1.1.1 (I never used the regular deployer in 1.1.1, so I don't know if that would have worked too). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2854) Inverse Classloader view
Inverse Classloader view Key: GERONIMO-2854 URL: https://issues.apache.org/jira/browse/GERONIMO-2854 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0-M2 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0-M2 Inverse classloader view to navigate through classloader's parent which will be child nodes in dojo tree. As discussed in thread http://www.mail-archive.com/dev@geronimo.apache.org/msg41904.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473370 ] Rakesh Midha commented on GERONIMO-2742: Try adding org.apache.geronimo.configs/sharedlib/2.0-SNAPSHOT/car in /var/config/offline-deployer-list if you want to use sharedlib with offline build. If you face an error specified in http://issues.apache.org/jira/browse/GERONIMO-2765 please let us know, otherwise things should work fine for you. Thanks Rakesh Deployer cannot access libaries in shared/lib and shared/classes Key: GERONIMO-2742 URL: https://issues.apache.org/jira/browse/GERONIMO-2742 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: Windows XP, Geronimo 1.2-beta Reporter: Aman Nanner Attachments: sharedlib-2.0.zip, sharedlib.zip, testing.ear.zip It seems that when running the deployer to deploy my EAR file, the classloaders during deployment cannot access the shared/lib and shared/classes directory. My app has dependencies on libraries that are stored in both shared/classes and shared/lib. Because these libraries cannot be found, the deployment fails. Neither regular deployment nor hot deployment works. My EAR file used to hot deploy properly in Geronimo 1.1.1 (I never used the regular deployer in 1.1.1, so I don't know if that would have worked too). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471318 ] Rakesh Midha commented on GERONIMO-2742: Hello Aman Thanks for the files. I think there is no problem with sharedlib. The problem is in your jar files class org.jgroups.MembershipLister is missing. Here is how I can prove it: (case 1) 1. unzip your sharedlib.zip file in sharedlib directory 2. try to deploy testing.ear It gives noclassdeffound for org/jgroups/MembershipListner Now...(case 2) 1. delete unziped jar files from sharedlib directory 2. try to deploy testing.ear It gives noclassdeffound for org/jboss/cache/TreeCacheMBean which means in case 1. org/jboss/cache/TreeCacheMBean is found by org/jgroups/MembershipListner us not try adding that file. Please try and let me know if it works? I think it should. Thanks Rakesh Deployer cannot access libaries in shared/lib and shared/classes Key: GERONIMO-2742 URL: https://issues.apache.org/jira/browse/GERONIMO-2742 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: Windows XP, Geronimo 1.2-beta Reporter: Aman Nanner Attachments: sharedlib.zip, testing.ear.zip It seems that when running the deployer to deploy my EAR file, the classloaders during deployment cannot access the shared/lib and shared/classes directory. My app has dependencies on libraries that are stored in both shared/classes and shared/lib. Because these libraries cannot be found, the deployment fails. Neither regular deployment nor hot deployment works. My EAR file used to hot deploy properly in Geronimo 1.1.1 (I never used the regular deployer in 1.1.1, so I don't know if that would have worked too). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471601 ] Rakesh Midha commented on GERONIMO-2742: Hello With your new sharedlib your application is getting deployed without any problem. I tried normal deployment. As David suggested, check if org.apache.geronimo.configs/sharedlib/2.0-SNAPSHOT/car is started on your server. try it and let us know if problem persists. Thanks Rakesh Deployer cannot access libaries in shared/lib and shared/classes Key: GERONIMO-2742 URL: https://issues.apache.org/jira/browse/GERONIMO-2742 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: Windows XP, Geronimo 1.2-beta Reporter: Aman Nanner Attachments: sharedlib-2.0.zip, sharedlib.zip, testing.ear.zip It seems that when running the deployer to deploy my EAR file, the classloaders during deployment cannot access the shared/lib and shared/classes directory. My app has dependencies on libraries that are stored in both shared/classes and shared/lib. Because these libraries cannot be found, the deployment fails. Neither regular deployment nor hot deployment works. My EAR file used to hot deploy properly in Geronimo 1.1.1 (I never used the regular deployer in 1.1.1, so I don't know if that would have worked too). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes
[ https://issues.apache.org/jira/browse/GERONIMO-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470843 ] Rakesh Midha commented on GERONIMO-2742: I tried using sharedlib and it works fine for me. Are you sure you added in your plan file sys:environment dependencies dependency artifactIdsharedlib/artifactId /dependency /dependencies /sys:environment If that's not a problem than please provide more details on setup, and if possible share your ear file and libraries Deployer cannot access libaries in shared/lib and shared/classes Key: GERONIMO-2742 URL: https://issues.apache.org/jira/browse/GERONIMO-2742 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: Windows XP, Geronimo 1.2-beta Reporter: Aman Nanner It seems that when running the deployer to deploy my EAR file, the classloaders during deployment cannot access the shared/lib and shared/classes directory. My app has dependencies on libraries that are stored in both shared/classes and shared/lib. Because these libraries cannot be found, the deployment fails. Neither regular deployment nor hot deployment works. My EAR file used to hot deploy properly in Geronimo 1.1.1 (I never used the regular deployer in 1.1.1, so I don't know if that would have worked too). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Attachment: appdoc.patch appclientdoc.patch alldoc.patch Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Attachment: jettyconfigdoc.patch connectordoc.patch attributedoc.patch Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Attachment: moduledoc.patch logindoc.patch jettydoc.patch Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Attachment: (was: jettydoc.patch) Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Attachment: (was: moduledoc.patch) Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Attachment: moduledoc.patch logindoc.patch jettydoc.patch Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Attachment: securitydoc.patch plugindoc.patch namingdoc.patch Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Attachment: webdoc.patch tomcatdoc.patch tomcatconfigdoc.patch Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470565 ] Rakesh Midha commented on GERONIMO-2661: Attached is the patch for improved documentation for all the schema files. You can either use alldoc.patch which contains all the updated schema files or use individual patch for seperate schems (eg use appdoc.patch for application schema and appclientdoc.patch for app client schema) Please note : 1. All the schema as license included as header as well as annotation, the reason if some viewers shows the license if it is included as annotation (this is required if schema is exposed through documentation produced by such viewers) 2. I tried to add documentation for all the attributes and elements, if required it can be changed or improved Please review and commit Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: 2.0 Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ https://issues.apache.org/jira/browse/GERONIMO-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2661: --- Patch Info: [Patch Available] Fix Version/s: (was: Wish List) 2.0 Assignee: (was: Rakesh Midha) Marking patch available unassigning so that someone can review and commit Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: https://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Priority: Minor Fix For: 2.0 Attachments: alldoc.patch, appclientdoc.patch, appdoc.patch, attributedoc.patch, connectordoc.patch, jettyconfigdoc.patch, jettydoc.patch, logindoc.patch, moduledoc.patch, namingdoc.patch, plugindoc.patch, securitydoc.patch, tomcatconfigdoc.patch, tomcatdoc.patch, webdoc.patch Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2690: --- Attachment: classloaderViewLinks.patch New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Kevan Miller Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2690: --- Attachment: classloaderViewLinks.patch New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Kevan Miller Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2690: --- Attachment: (was: classloaderViewLinks.patch) New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Kevan Miller Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465368 ] Rakesh Midha commented on GERONIMO-2690: Attached classloaderViewLinks.patch, this patch fixes the OutOfMemory problem with Classloader viewer. This patch using linking of Dojo Treenodes for classloaders which occurs multiple times in the tree. From the user prespective this will not make any difference but interally the whole StringTree size is reduce. Earlier the size of StringTree for dojo tree children was 6542173 chars, and not it is reduced to 665019 chars for my Geronimo server. This is imporvement of app 90%, and it is visible is tree loading, now it is much quicker. Please review and commit. Thanks Rakesh New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Kevan Miller Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465370 ] Rakesh Midha commented on GERONIMO-2690: Oh I missed to give some important points for the patch. Please note: 1. The links are marked by link::', so any class or classloader starting with link:: may not work properly, but I don't think we will have any classloader, class or interface name starting with 'link::' 2. For dojo tree link loading 'afterExpand' event is used, ideally 'beforeExpand' should be used, but 'beforeExpand' event is never published in current dojo version. 3. All the methods in ClassLoaderRegistry are synchronized for thread avoiding concurent modification. Thanks Rakesh New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Kevan Miller Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2676) Web Application without required jars throws NullPointer
[ https://issues.apache.org/jira/browse/GERONIMO-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464209 ] Rakesh Midha commented on GERONIMO-2676: Hello KK I tried to reproduce this problem with quite a number of scenerio's but could not. I even tried the applications myfaces applications (thanks for sharing them with me). I tried to look into code and from what I understand the place where you were getting null pointer is not related to dependencies and I am not sure but looks like the problem is some where else. Can you please recheck the scenerio you have and confim. Thanks Rakesh Web Application without required jars throws NullPointer Key: GERONIMO-2676 URL: https://issues.apache.org/jira/browse/GERONIMO-2676 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0 Reporter: Krishnakumar B I have tried deploying applications like ActiveBPEL and MyFaces examples on geronimo. If i dont add the required jars for these application's to run i get a NullPointerException. The service J2EEApplication=null,j2eeType=WebModule,name=default/myfaces-examp le-simple-1.1.5-SNAPSHOT/1166707464231/war did not start because the doStart met hod threw an exception. java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:396) at org.apache.naming.resources.DirContextURLStreamHandler.bind(DirContex tURLStreamHandler.java:234) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppCo ntext.java:477) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:984) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:543) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:378) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:527) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:508) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$Enhan cerByCGLIB$$b42bfad1.startConfiguration(generated) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCom mand.java:67) at java.lang.Thread.run(Thread.java:595) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:407) ... 14 more A more user friendly exception will help the user to add the required jars. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: G2689-2690-2691_updated.patch New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Kevan Miller Fix For: 2.0 Attachments: allviews.patch, common.patch, G2689-2690-2691.patch, G2689-2690-2691_updated.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463908 ] Rakesh Midha commented on GERONIMO-2689: minor change in all patch, check for null J2EE New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Kevan Miller Fix For: 2.0 Attachments: allviews.patch, common.patch, G2689-2690-2691.patch, G2689-2690-2691_updated.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463822 ] Rakesh Midha commented on GERONIMO-2689: Thanks Kevan, for spending time and integrating this patch. 1) About finalize(), I didnt notice that I used upper case 'F', you are right it should be lower case finalize . Now about using destroy()/finalize(). I used all three technicques finalize(), destroy() and weak references to remove ClassLoaders from registry, not just because I am worried about circular reference, but also because I don't want to depend too much on weak references or finalize() implementation in GC and destroy() calling from Geronimo code. I want to leave no chance hence used all the precautions I could. (In no case I want Classloadere to be not GC'd because of its refernce in Registry). I hope this convince you for using combination of destroy()/finalize() and weak references. 2) You are right, I spent some time on this code and didnt took the latest from SVN before making patch, my mistake, do you want me to do that for me. I promise I will take care of this from next patch onways, forgive this time. Christopher, I could not figure out what dojo widgets names you changed. Can you list them please. Thanks New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Kevan Miller Fix For: 2.0 Attachments: allviews.patch, common.patch, G2689-2690-2691.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-720) server should give client more feedback on deployment and starting configurations.
[ https://issues.apache.org/jira/browse/GERONIMO-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463464 ] Rakesh Midha commented on GERONIMO-720: --- Hello David I was trying to work on your suggestions in this JIRA, but after looking at code and from my understanding, I hit the point where I am thinking the above information may not be valid for individual components. I hope I am not missing some critical factor, if so help me understand. - when a configuration is started, it would be useful to list the gbeans that are not started. This is currently done when you start up the server and has proved very useful in detecting problems early. - When a configuration is started, all its dependencies and child configurations and coorsponding gbeans are started and if any of those fail to start, the configuration start up fails. Unlike server startup where few gbeans may fail to start and even than server can be decalred started. For this case my understanding is ther won't be any failed gbean if the component is deployed/Started. - when an app is deployed, there are usually lots of gbean names resolved. Listing these for the client could provide an easy way to check that things got hooked up the way you expected. To some extent this is done in https://issues.apache.org/jira/browse/GERONIMO-1285, which list all the modules/gbeans started with startup of configuration. What other gbeans are resolved with this, can you give an example. If there are other gbean names resolve I am not sure if we can send it to client (we can log them as information in logs), but sending them back to client may be difficult. The reason why I say that is the implementation of ConfigurationManger, say if we want to start a configuration we use LifecycleResults startConfiguration(Artifact configurationId), now only data which can be returned back to client is data available in LifecycleResults, and the only info it cna contain is list of configurations/gbeans started. (I think thats how it should be according to protocol) Thanks Rakesh server should give client more feedback on deployment and starting configurations. -- Key: GERONIMO-720 URL: https://issues.apache.org/jira/browse/GERONIMO-720 Project: Geronimo Issue Type: New Feature Components: deployment Affects Versions: 1.0-M3 Reporter: David Jencks Fix For: 1.x The server should give the client more information when you deploy a package or start a module. Examples of useful information are: -- when an app is deployed, there are usually lots of gbean names resolved. Listing these for the client could provide an easy way to check that things got hooked up the way you expected. -- when a configuration is started, it would be useful to list the gbeans that are not started. This is currently done when you start up the server and has proved very useful in detecting problems early. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-720) server should give client more feedback on deployment and starting configurations.
[ https://issues.apache.org/jira/browse/GERONIMO-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463479 ] Rakesh Midha commented on GERONIMO-720: --- Thanks David for Quick response. I agree with what you said. About the logging, I think we need to have logging code in whole kernel, deployment and jsr88 modules, and I think we should open another JIRA for missing logging ( this is just a small part of missing logging), I would like this JIRA to be closed. Agreed? server should give client more feedback on deployment and starting configurations. -- Key: GERONIMO-720 URL: https://issues.apache.org/jira/browse/GERONIMO-720 Project: Geronimo Issue Type: New Feature Components: deployment Affects Versions: 1.0-M3 Reporter: David Jencks Fix For: 1.x The server should give the client more information when you deploy a package or start a module. Examples of useful information are: -- when an app is deployed, there are usually lots of gbean names resolved. Listing these for the client could provide an easy way to check that things got hooked up the way you expected. -- when a configuration is started, it would be useful to list the gbeans that are not started. This is currently done when you start up the server and has proved very useful in detecting problems early. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: allviews.patch New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: allviews.patch, common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462999 ] Rakesh Midha commented on GERONIMO-2689: Posting a combined patch allview.patch which provides all the three views (JIRA 2689, JIRA 2690 and JIRA 2691) Please review and commit. THanks New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: allviews.patch, common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2707) Cannot deploy app client from ear
[ https://issues.apache.org/jira/browse/GERONIMO-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463047 ] Rakesh Midha commented on GERONIMO-2707: Hello Dario I am not sure what source code are you looking at. I tried deploying a bank sample ear with bankclient.jar in it and I was able to deploy it.(I tried for both geronimo-1.1.1 and 2.0). Here is the output C:\geronimo\geronimo-1.1.1\bindeploy.bat --user system --password manager deplo y c:\geronimo\sample\bank\releases\Bank.ear Using GERONIMO_BASE: C:\geronimo\geronimo-1.1.1 Using GERONIMO_HOME: C:\geronimo\geronimo-1.1.1 Using GERONIMO_TMPDIR: C:\geronimo\geronimo-1.1.1\var\temp Using JRE_HOME:c:\Progra~1\Java\jdk1.5.0_01 Deployed samples/Bank/1.0/car `- BankWeb.war @ http://libspie:8080/Bank `- BankEJB.jar `- bankclient.jar `- tranql-connector-1.2.rar Can you please share your application.xml, application-client.xml and geronimo deployment descriptors (if you are using). Thanks Rakesh Cannot deploy app client from ear - Key: GERONIMO-2707 URL: https://issues.apache.org/jira/browse/GERONIMO-2707 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1 Environment: win xp, java 1.6.0, geronimo 1.1.1, core 2 duo 4GB, myeclipse 5, wtp 1.5.2 Reporter: Dario Andrade When trying to deploy an ear with an application client, I get this error: From the code, I can see the application client config builder is not defined in the j2ee deployer. Publishing failed Distribution of configuration failed. See log for details. Cannot deploy app client; No app client deployer defined: GManiaBatchClient.jar org.apache.geronimo.common.DeploymentException: Cannot deploy app client; No app client deployer defined: GManiaBatchClient.jar at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:725) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:364) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$601a27b4.getDeploymentPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1424) at
[jira] Closed: (GERONIMO-2707) Cannot deploy app client from ear
[ https://issues.apache.org/jira/browse/GERONIMO-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha closed GERONIMO-2707. -- Resolution: Invalid Fix Version/s: 2.0 Closed this issue as a user error. (Invalid problem). The service was disabled and is enabled by default. So it is working as desired. Cannot deploy app client from ear - Key: GERONIMO-2707 URL: https://issues.apache.org/jira/browse/GERONIMO-2707 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1 Environment: win xp, java 1.6.0, geronimo 1.1.1, core 2 duo 4GB, myeclipse 5, wtp 1.5.2 Reporter: Dario Andrade Fix For: 2.0 When trying to deploy an ear with an application client, I get this error: From the code, I can see the application client config builder is not defined in the j2ee deployer. Publishing failed Distribution of configuration failed. See log for details. Cannot deploy app client; No app client deployer defined: GManiaBatchClient.jar org.apache.geronimo.common.DeploymentException: Cannot deploy app client; No app client deployer defined: GManiaBatchClient.jar at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:725) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:364) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$601a27b4.getDeploymentPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1424) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1262) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1364) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:786) at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at
[jira] Closed: (GERONIMO-1079) Better error for missing primkey-field
[ https://issues.apache.org/jira/browse/GERONIMO-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha closed GERONIMO-1079. -- Resolution: Fixed Fix Version/s: (was: Verification Required) 2.0-M1 Closing based on my previous comment - Looks like this problem is fixed in OpenEJB If my primary key class is java.lang.Integer I get failure with following message Error: Unable to distribute myphonebook-ejb.jar: Could not deploy module Invalid primary key class: ejbName=MyPhonebookBean pkClass=class java.lang.String If my primary key class is any other class with non-static field Error: Unable to distribute myphonebook-ejb.jar: Could not deploy module caused by EJB [MyPhonebookBean] is misconfigured: could not find CMP fields for following pk fields: [ABC] [XYZ] The reason being a If primary key class is provided and primary key name is not provided, deployer consider it as a compound key. Compound key with no non-static field is invalid primary key hence Invalid primary key class in case of java.lang.Integer. In other cases where compound key contains non-static field could not found fields for following pk fields for all the non-static fields. I think this is working as required. Please confirm and close this JIRA. Better error for missing primkey-field -- Key: GERONIMO-1079 URL: https://issues.apache.org/jira/browse/GERONIMO-1079 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, OpenEJB Affects Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 2.0-M1 I forgot the primkey-field for my CMP entity, and I got this: Error: Unable to distribute LoadMagus.ear: Could not deploy module caused by EJB [TestRunMachine] is misconfigured: could not find CMP fields for following pk fields: [TYPE] [MAX_VALUE] [MIN_VALUE] Now, I don't know where it got TYPE, MAX_VALUE, and MIN_VALUE from -- those are not fields on my EJB or the table or anything. I did have a prim-key-class set to java.lang.Integer, so perhaps it picked up the static fields on java.lang.Integer (if so why? I wouldn't have thought statics were relevant). It would be better if the error said missing primkey-field or prim-key-class does not have properties matching CMP field names or something like that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2689) New View for JNDI name in all the contexts
New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2691) New view for the hierarchical modules and linked dependencies
New view for the hierarchical modules and linked dependencies - Key: GERONIMO-2691 URL: https://issues.apache.org/jira/browse/GERONIMO-2691 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Dependencies in Geronimo get complex sometimes (in fact lot of times). We spend lot of time in knowing which components has what dependencies. Knowing the dependencies of each module in hierarchical fashion will be a nice feature in console. I would like to add a view in console which can show all the modules, repository items and link them based on dependencies. This item was discussed before in thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: jndi.gif jndiview2689.patch common.patch New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462421 ] Rakesh Midha commented on GERONIMO-2689: Attached is the common.patch and jndiview2689.patch which implements JNDI Viewer console view. The jndi.gif file shows how this view will look. This patch adds console-standard.JMXViewer entity in portlet registry and also adds all the required redirections and entries in web.xml. The approach is to use componentContext gbean attribute from each component to get the context for component and than show it in dojo tree. To load dojo tree nodes lazily, the StringTree instances are converted to JSON string, and setChildren is called to lazy loading of childrens on expension. It adds JNDIViewPortlet.java, which getJSONTrees() build the json tree using kernel getattribute method on component gbeans. To use the patches first apply common.patch which adds StringTree.java and TreeDocIcon.css and than apply jndiview2689.patch. The common patch is also used in JIRA 2690 and 2691. New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: common.patch New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: (was: common.patch) New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Attachment: navigation.gif New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts
[ https://issues.apache.org/jira/browse/GERONIMO-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2689: --- Description: So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. was: So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. Patch Info: [Patch Available] Navigation.gif is for just showing purpose, the current patch doesn't put items in debug view but directly in main tree. Marking patch available. New View for JNDI name in all the contexts -- Key: GERONIMO-2689 URL: https://issues.apache.org/jira/browse/GERONIMO-2689 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, jndi.gif, jndiview2689.patch, navigation.gif So many times we hit the Exception NamingNotFound, most of the times it happens because of user error, missing references, wrong names or path or user working in different context and system looking in some other context. I think it would be nice if in a console we can have a view of what all names are binded or available in contexts of each application / module or component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2690: --- Attachment: classloader.gif classloaderView2690.patch common.patch New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2690: --- Description: Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. was: Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. Patch Info: [Patch Available] New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2690) New view for all the classloaders and classes loaded in it
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462425 ] Rakesh Midha commented on GERONIMO-2690: Attached is the common.patch and classloaderview2690.patch which implements classloaderViewer console view. The classloader.gif file shows how this view will look. This view shows all the classloaders and its classes/interfaces in hierarchical fashion in which they are loaded. To facilitate locating of class of interest the tree view can be searched. Tha approach used to keep track of all the class loaders and its parent/childrens is by keeping a registry of classloaders. This is done by uusing ClassloaderRegistry class which keeps WeakReference of all the loaded class loaders. As we are using WeakReferences this registry does not hinder Garbage colection if the classloader is destroyed somewhere else. All the class loaders in Geronimo ie. ConfigurationClassLoader and MultiParentClassLoader are responsible for registering and unregistring of classloaders in registry. (if we forget to unregister, weak reference as well as destroy method takes care of GC). The classloader tree grows like anything, so we are using dojo tree nodes lazly loaded. To load dojo tree nodes lazily, the StringTree instances are converted to JSON string, and setChildren is called to lazy loading of childrens on expension. To use the patches first apply common.patch which adds StringTree.java and TreeDocIcon.css and than apply classloaderView2690.patch. The common patch is also used in JIRA 2689 and 2691. Few points which are worth noticing here : 1. The tree grows like anything and may take some time to intial loading ( for me it is taking 15 secs for full geronimo server for tomcat). 2. Classloader registry is introduced which some people may not like. 3. Please notice addClasses method in ClassLoaderViewPortlet.java, it does something which seem like illigal. It gets names of classes and interfaces from private Vector of Classloader class. This is the only way in which all the classes and interfaces names are available. I have tried this on Sun and IBM JDK and it works fine on it. Sometime later if these JDK's changes the name or type of variable classes in Classloader.java class this functaionality may not work. Thanks New view for all the classloaders and classes loaded in it -- Key: GERONIMO-2690 URL: https://issues.apache.org/jira/browse/GERONIMO-2690 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: classloader.gif, classloaderView2690.patch, common.patch Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers. So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader. I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2691) New view for the hierarchical modules and linked dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2691: --- Attachment: dependency.gif dependencyview2691.patch common.patch New view for the hierarchical modules and linked dependencies - Key: GERONIMO-2691 URL: https://issues.apache.org/jira/browse/GERONIMO-2691 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, dependency.gif, dependencyview2691.patch Dependencies in Geronimo get complex sometimes (in fact lot of times). We spend lot of time in knowing which components has what dependencies. Knowing the dependencies of each module in hierarchical fashion will be a nice feature in console. I would like to add a view in console which can show all the modules, repository items and link them based on dependencies. This item was discussed before in thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2691) New view for the hierarchical modules and linked dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462428 ] Rakesh Midha commented on GERONIMO-2691: Attached is the common.patch and dependencyview2691.patch which implements dependencyViewer console view. The dependency.gif file shows how this view will look. This view shows all the components and repository items and its dependencies in hierarchical fashion in which they are loaded. To facilitate locating of items of interest the tree view can be searched. The configuration provided in kernel is used to get dependencies. It is same approach as one used in config section of console, the main difference being, 1. Everything is shown in a dojo tree, which means it is hierarchical and easily traceable. 2. Config section used dependency manager and shows only serviceparents(), where as this view directly list the direct dependencies as well as serviceparents The tree can grow like anything, so we are using dojo tree nodes lazly loaded. To load dojo tree nodes lazily, the StringTree instances are converted to JSON string, and setChildren is called to lazy loading of childrens on expension. To use the patches first apply common.patch which adds StringTree.java and TreeDocIcon.css and than apply dependencyView2691.patch. The common patch is also used in JIRA 2689 and 2690. Clicking the dependency node will select the component so that you can see its further dependencies. Thanks New view for the hierarchical modules and linked dependencies - Key: GERONIMO-2691 URL: https://issues.apache.org/jira/browse/GERONIMO-2691 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, dependency.gif, dependencyview2691.patch Dependencies in Geronimo get complex sometimes (in fact lot of times). We spend lot of time in knowing which components has what dependencies. Knowing the dependencies of each module in hierarchical fashion will be a nice feature in console. I would like to add a view in console which can show all the modules, repository items and link them based on dependencies. This item was discussed before in thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2691) New view for the hierarchical modules and linked dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh Midha updated GERONIMO-2691: --- Patch Info: [Patch Available] New view for the hierarchical modules and linked dependencies - Key: GERONIMO-2691 URL: https://issues.apache.org/jira/browse/GERONIMO-2691 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: common.patch, dependency.gif, dependencyview2691.patch Dependencies in Geronimo get complex sometimes (in fact lot of times). We spend lot of time in knowing which components has what dependencies. Knowing the dependencies of each module in hierarchical fashion will be a nice feature in console. I would like to add a view in console which can show all the modules, repository items and link them based on dependencies. This item was discussed before in thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200607.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1642) Deployment plan namespace validation
[ http://issues.apache.org/jira/browse/GERONIMO-1642?page=all ]
Rakesh Midha updated GERONIMO-1642:
---
Attachment: namespace1642.patch
I tried this and found following results
-
for geronimo-web.xml
--
It gives Error: Unable to distribute myphonebook-web.war: Cannot handle web
plan with namespace http://geronimo.apache.org/xml/ns/j2ee/web-1.21
-- expecting http://geronimo.apache.org/xml/ns/j2ee/web-1.2 or
http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.2
I think it was fixed in revision 406804
for geronimo-ra.xml
-
It gives error: The document is not a
[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/connector-1.2:
document element namespace mismatch expected
http://geronimo.apache.org/xml/ns/j2ee/connector-1.2; got
http://geronimo.apache.org/xml/ns/j2ee/connector-1.1a;
Again it is fixed
geronimo-application.xml, openejb-jar.xml and application-client
--
It is a problem mentioned in JIRA
---
---
The attached patch tries to fix it in generic way using
SchemaConversionUtils.java
It tries to check for wrong element or namespace and instead of returning null,
it throws XmlException with message
Cannot find desiredElement application with
namespace{http://geronimo.apache.org/xml/ns/j2ee/application-1.2} in
the plan provided.
So after applying patch, geronimo-application.xml, openejb-jar.xml and
application-client
gives required error msg --
Cannot find desiredElement application with
namespace{http://geronimo.apache.org/xml/ns/j2ee/application-1.2} in
the plan provided.
I hope this is what is desired.
Thanks
Deployment plan namespace validation
Key: GERONIMO-1642
URL: http://issues.apache.org/jira/browse/GERONIMO-1642
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment, OpenEJB, web
Affects Versions: 1.1
Reporter: Aaron Mulder
Assigned To: Rakesh Midha
Priority: Critical
Fix For: 1.1.x
Attachments: namespace1642.patch
When you deploy with a geronimo deployment plan packaged in the archive, but
it has the wrong namespace, the file is ignored. If anything, you get a
message saying the plan is required, or that the archive is not a
WAR/JAR/etc. We should have special detection for geronimo-application.xml,
geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the
file is present but has the wrong namespace, and prints a suggestive WARN or
ERROR message to the console. Probably for the application.xml, web.xml,
ra.xml, and ejb-jar.xml too.
People have asked for help on the mailing list several times recently when
they had this (bad namespace) problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1642) Deployment plan namespace validation
[ http://issues.apache.org/jira/browse/GERONIMO-1642?page=all ]
Rakesh Midha updated GERONIMO-1642:
---
Patch Info: [Patch Available]
Fix Version/s: 2.0
(was: 1.1.x)
Assignee: (was: Rakesh Midha)
Hello David
You are right, in number of cases it is already fixed, but there are still few
cases where it is a problem. Though I didnt like the way it is fixed in
geronimo-web.xml, via revision 406804. In a way it hardcodes the namespace
which I didnt like.
Anyways for failing cases, geronimo-application.xml, openejb-jar.xml and
application-client
I attached to patch, which actually doesn't check for any particular version of
schema but just validates the root element, and if root element or namespace is
wrong it throws
Cannot find desiredElement application with
namespace{http://geronimo.apache.org/xml/ns/j2ee/application-1.2} in
the plan provided.
What do you say? Can you please review it and commit it. It is just short
changes and will not take your lot of time. (small amount of changes, but one
of those cases where it take lot of time to find the place where fix should go
:-) )
Mark patch available and unassigning.
Thanks
Rakesh
Deployment plan namespace validation
Key: GERONIMO-1642
URL: http://issues.apache.org/jira/browse/GERONIMO-1642
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: web, deployment, OpenEJB
Affects Versions: 1.1
Reporter: Aaron Mulder
Priority: Critical
Fix For: 2.0
Attachments: namespace1642.patch
When you deploy with a geronimo deployment plan packaged in the archive, but
it has the wrong namespace, the file is ignored. If anything, you get a
message saying the plan is required, or that the archive is not a
WAR/JAR/etc. We should have special detection for geronimo-application.xml,
geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the
file is present but has the wrong namespace, and prints a suggestive WARN or
ERROR message to the console. Probably for the application.xml, web.xml,
ra.xml, and ejb-jar.xml too.
People have asked for help on the mailing list several times recently when
they had this (bad namespace) problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1642) Deployment plan namespace validation
[ http://issues.apache.org/jira/browse/GERONIMO-1642?page=all ] Rakesh Midha reassigned GERONIMO-1642: -- Assignee: Rakesh Midha Deployment plan namespace validation Key: GERONIMO-1642 URL: http://issues.apache.org/jira/browse/GERONIMO-1642 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment, OpenEJB, web Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Rakesh Midha Priority: Critical Fix For: 1.1.x When you deploy with a geronimo deployment plan packaged in the archive, but it has the wrong namespace, the file is ignored. If anything, you get a message saying the plan is required, or that the archive is not a WAR/JAR/etc. We should have special detection for geronimo-application.xml, geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the file is present but has the wrong namespace, and prints a suggestive WARN or ERROR message to the console. Probably for the application.xml, web.xml, ra.xml, and ejb-jar.xml too. People have asked for help on the mailing list several times recently when they had this (bad namespace) problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1749) Server Logs portlet - Web Access Log Viewer improvements
[ http://issues.apache.org/jira/browse/GERONIMO-1749?page=all ] Rakesh Midha updated GERONIMO-1749: --- Attachment: weblog1749.log Vamsi, I didnt see tat this JIRA is assigned to you, last week it was not, so this weekend I worked and fixed it. Sorry, if you are also working on it. Anyways I am attaching the patc. If you aven't fixed it yet please review and commit. Thanks Rakesh - Attached patch to support PUT and DELETE. Also added Start result and Max Result box. Server Logs portlet - Web Access Log Viewer improvements Key: GERONIMO-1749 URL: http://issues.apache.org/jira/browse/GERONIMO-1749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.2, 1.1 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 2.0 Attachments: weblog1749.log Web Access Log Viewer portlet improvements: 1. Request Method field provides only ANY, GET and POST values. It should provide search based on other Request Methods as well. In my opinion, PUT and DELETE are more important than GET and POST for an administrator searching thru webserver logs. 2. Provide Filter Max Results and Line range. Currently 1001 lines are displayed from the results and there is no way to browse all the results. 3. Dates and Date range should be validated and a message should be displyed if From date falls after To date. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1749) Server Logs portlet - Web Access Log Viewer improvements
[ http://issues.apache.org/jira/browse/GERONIMO-1749?page=all ] Rakesh Midha updated GERONIMO-1749: --- Patch Info: [Patch Available] Fix Version/s: 2.0 (was: Wish List) Marking patch available Server Logs portlet - Web Access Log Viewer improvements Key: GERONIMO-1749 URL: http://issues.apache.org/jira/browse/GERONIMO-1749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.2, 1.1 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 2.0 Attachments: weblog1749.log Web Access Log Viewer portlet improvements: 1. Request Method field provides only ANY, GET and POST values. It should provide search based on other Request Methods as well. In my opinion, PUT and DELETE are more important than GET and POST for an administrator searching thru webserver logs. 2. Provide Filter Max Results and Line range. Currently 1001 lines are displayed from the results and there is no way to browse all the results. 3. Dates and Date range should be validated and a message should be displyed if From date falls after To date. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2661) Make geronimo schema files more human readable
[ http://issues.apache.org/jira/browse/GERONIMO-2661?page=all ] Rakesh Midha reassigned GERONIMO-2661: -- Assignee: Rakesh Midha Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: http://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2661) Make geronimo schema files more human readable
[ http://issues.apache.org/jira/browse/GERONIMO-2661?page=comments#action_12459191 ] Rakesh Midha commented on GERONIMO-2661: Thanks for replying Matt. Sure, I will work on it and provide the required comments, I think it is important. I am keeping it in wishlist for now, because it may take some time. For now I am just assigning this JIRA to myself. As soon as I am in some shape I will move it to 2.0. Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: http://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Minor Fix For: Wish List Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-348) Invalid module path or references in plan should result in failed deployment or warning
[ http://issues.apache.org/jira/browse/GERONIMO-348?page=all ] Rakesh Midha updated GERONIMO-348: -- Patch Info: [Patch Available] Fix Version/s: 2.0 (was: Wish List) Assignee: (was: Rakesh Midha) Marking Patch available, making unassigned so tat someone can review and commit. thanks Invalid module path or references in plan should result in failed deployment or warning --- Key: GERONIMO-348 URL: http://issues.apache.org/jira/browse/GERONIMO-348 Project: Geronimo Issue Type: Bug Components: deployment Reporter: Jeremy Boynes Priority: Critical Fix For: 2.0 Attachments: noref348.patch If an EAR deployment plan contains a entry for a module but the path does not match that of a module in the application.xml then an error or warning should be issued at deployment time. A likely reason for this is that a developer copied the plan from another but forgot to change the uri entry for the submodule; or it could just be a simple typo. In either way, the plan won't match the intended module from the application.xml resulting in erroroneous behaviour. (added) In addition, elements in a plan that do not correspond to elements in the deployment descriptor should result in a warning or error. Examples would be an ejb listed in the openejb plan that does not correspond to an ejb in the ejb-jar.xml, or a resource-ref in the ejb that does not correspond to a resource-ref in the ejb-jar.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2665) CLONE -Invalid module path or references in plan should result in failed deployment or warning
CLONE -Invalid module path or references in plan should result in failed deployment or warning -- Key: GERONIMO-2665 URL: http://issues.apache.org/jira/browse/GERONIMO-2665 Project: Geronimo Issue Type: Bug Components: deployment Reporter: Rakesh Midha Assigned To: Rakesh Midha Priority: Critical Fix For: Wish List If an EAR deployment plan contains a entry for a module but the path does not match that of a module in the application.xml then an error or warning should be issued at deployment time. A likely reason for this is that a developer copied the plan from another but forgot to change the uri entry for the submodule; or it could just be a simple typo. In either way, the plan won't match the intended module from the application.xml resulting in erroroneous behaviour. (added) In addition, elements in a plan that do not correspond to elements in the deployment descriptor should result in a warning or error. Examples would be an ejb listed in the openejb plan that does not correspond to an ejb in the ejb-jar.xml, or a resource-ref in the ejb that does not correspond to a resource-ref in the ejb-jar.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-348) Invalid module path or references in plan should result in failed deployment or warning
[ http://issues.apache.org/jira/browse/GERONIMO-348?page=all ] Rakesh Midha updated GERONIMO-348: -- Attachment: noref348.patch Added code to check if plan contains refrences which are not defined in deployment descriptors. Now we get deployment failure if plan contains Resource Refs Web Services Refs Admin Object refs missing in deployment descriptor. Also created new Jira in OpenEJB http://issues.apache.org/jira/browse/OPENEJB-407 to check same for EJB Remote refs EJB Local refs Seperate patch provided in openejb-407 for fixing openejb part. Invalid module path or references in plan should result in failed deployment or warning --- Key: GERONIMO-348 URL: http://issues.apache.org/jira/browse/GERONIMO-348 Project: Geronimo Issue Type: Bug Components: deployment Reporter: Jeremy Boynes Assigned To: Rakesh Midha Priority: Critical Fix For: Wish List Attachments: noref348.patch If an EAR deployment plan contains a entry for a module but the path does not match that of a module in the application.xml then an error or warning should be issued at deployment time. A likely reason for this is that a developer copied the plan from another but forgot to change the uri entry for the submodule; or it could just be a simple typo. In either way, the plan won't match the intended module from the application.xml resulting in erroroneous behaviour. (added) In addition, elements in a plan that do not correspond to elements in the deployment descriptor should result in a warning or error. Examples would be an ejb listed in the openejb plan that does not correspond to an ejb in the ejb-jar.xml, or a resource-ref in the ejb that does not correspond to a resource-ref in the ejb-jar.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-348) Invalid module path or references in plan should result in failed deployment or warning
[ http://issues.apache.org/jira/browse/GERONIMO-348?page=all ] Rakesh Midha reassigned GERONIMO-348: - Assignee: Rakesh Midha Invalid module path or references in plan should result in failed deployment or warning --- Key: GERONIMO-348 URL: http://issues.apache.org/jira/browse/GERONIMO-348 Project: Geronimo Issue Type: Bug Components: deployment Reporter: Jeremy Boynes Assigned To: Rakesh Midha Priority: Critical Fix For: Wish List If an EAR deployment plan contains a entry for a module but the path does not match that of a module in the application.xml then an error or warning should be issued at deployment time. A likely reason for this is that a developer copied the plan from another but forgot to change the uri entry for the submodule; or it could just be a simple typo. In either way, the plan won't match the intended module from the application.xml resulting in erroroneous behaviour. (added) In addition, elements in a plan that do not correspond to elements in the deployment descriptor should result in a warning or error. Examples would be an ejb listed in the openejb plan that does not correspond to an ejb in the ejb-jar.xml, or a resource-ref in the ejb that does not correspond to a resource-ref in the ejb-jar.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2660) Uniqueness constraint missing in multiple places in geronimo schema's
Uniqueness constraint missing in multiple places in geronimo schema's - Key: GERONIMO-2660 URL: http://issues.apache.org/jira/browse/GERONIMO-2660 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Uniqueness constraint is missing in multiple places in geronimo schema's, this allows the multiple attributes to be specified in geronimo plan files without any problem. Few examples: In geronimo-web and openejb, multiple ejb-local-ref or any references with same ref-name are allowed, which is wrong. In openejb multiple cmp fields with same name are allowed. These are just two examples, if we look at any xsd file we dont have many constraints, if we look at coorsponding j2ee descriptors schema we will see all the required constraints. It is not a mandatory feature to have, but I think right guidelines should be followed. It will require lot of changes though, in all the schema files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2661) Make geronimo schema files more human readable
Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: http://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Fix For: 2.0 Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2661) Make geronimo schema files more human readable
[ http://issues.apache.org/jira/browse/GERONIMO-2661?page=all ] Rakesh Midha updated GERONIMO-2661: --- Description: Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? was: Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? Priority: Minor (was: Major) Its not essential but if required, so changing the priority to minor. Will work on it when have some time. Make geronimo schema files more human readable -- Key: GERONIMO-2661 URL: http://issues.apache.org/jira/browse/GERONIMO-2661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation Affects Versions: 2.0 Environment: Any Reporter: Rakesh Midha Priority: Minor Fix For: 2.0 Geronimo schema files are the files which are basically exposed to all the user's to follow the guidelines while developing there plan files. These schema files should have lot of documentation just like j2ee descriptor's schema's. All the fields should be described. Schema formatting provides a nice option to do this by specifying xs:annotation xs:documentation lang=endocumentation for each element goes here/xs:documentation /xs:annotation for each and every element in schema files. I think this will make it more human readable, i believe that every file which is openly exposed to user's should have lot of documentation for readbility. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2402) Redeployment fails after third iteration.
[ http://issues.apache.org/jira/browse/GERONIMO-2402?page=comments#action_12456716 ] Rakesh Midha commented on GERONIMO-2402: You were right about (modules != null) ... is redundant. thanks for closing Vamsi Redeployment fails after third iteration. - Key: GERONIMO-2402 URL: http://issues.apache.org/jira/browse/GERONIMO-2402 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1, 1.1.1 Environment: JDK 1.4.2_08, Windows/XP Pro, Version 2002 SP/2 Reporter: Fran Varin Assigned To: Vamsavardhana Reddy Priority: Critical Fix For: 1.2, 1.1.2, 2.0-M1 Attachments: hotdeployupdate.patch Here is a modified copy of the test case that reproduces the bug. In its original state there were some screen shots included for clarity sake. However, it is not possible to include those here. The applicaiton that was used in concert with this test case was an extremely simply project that just included one JSP. There was no geronimo-web.xml used in the project and it was deployed in exploded form. Step 1 - Launch Geronimo ? For this test I used the 1.1.1-RC3 Version. ? I am pointing to Java SE v1.4.2_08 ? The standard startup.bat was used to start the server with no modification. ? The application does not contain a Geronimo-web.xml descriptor. ? Below are all of the message on the console after the Geronimo started. Note that the application was deployed Booting Geronimo Kernel (in Java 1.4.1_02)... Module 1/20 geronimo/rmi-naming/1.1.1-rc3/car started in .265s Module 2/20 geronimo/j2ee-server/1.1.1-rc3/car started in .563s Module 3/20 geronimo/j2ee-security/1.1.1-rc3/car started in .547s Module 4/20 geronimo/axis/1.1.1-rc3/carstarted in .078s Module 5/20 geronimo/openejb/1.1.1-rc3/car started in .313s Module 6/20 geronimo/system-database/1.1.1-rc3/car started in 1.750s Module 7/20 geronimo/activemq-broker/1.1.1-rc3/car started in 1.188s Module 8/20 geronimo/activemq/1.1.1-rc3/carstarted in .390s Module 9/20 geronimo/tomcat/1.1.1-rc3/car started in 2.015s Module 10/20 geronimo/geronimo-gbean-deployer/1.1.1-rc3/car started in .297s Module 11/20 geronimo/j2ee-deployer/1.1.1-rc3/car started in .234s Module 12/20 geronimo/openejb-deployer/1.1.1-rc3/carstarted in .266s Module 13/20 geronimo/client-deployer/1.1.1-rc3/car started in .047s Module 14/20 geronimo/axis-deployer/1.1.1-rc3/car started in .078s Module 15/20 geronimo/sharedlib/1.1.1-rc3/car started in .016s Module 16/20 geronimo/tomcat-deployer/1.1.1-rc3/car started in .093s Module 17/20 geronimo/welcome-tomcat/1.1.1-rc3/car started in .266s Module 18/20 geronimo/webconsole-tomcat/1.1.1-rc3/car started in 4.297s Module 19/20 geronimo/remote-deploy-tomcat/1.1.1-rc3/carstarted in .234s Module 20/20 geronimo/hot-deployer/1.1.1-rc3/carstarted in .343s Startup completed in 16 seconds Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8009 0.0.0.0 Tomcat Connector AJP 8080 0.0.0.0 Tomcat Connector HTTP 8443 0.0.0.0 Tomcat Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-tomcat/1.1.1-rc3/car RAR: geronimo/activemq/1.1.1-rc3/car WAR: geronimo/remote-deploy-tomcat/1.1.1-rc3/car WAR: geronimo/welcome-tomcat/1.1.1-rc3/car Web Applications: http://RI150WS311:8080/ http://RI150WS311:8080/console http://RI150WS311:8080/console-standard http://RI150WS311:8080/remote-deploy Geronimo Application Server started 11:15:15,111 INFO [Hot Deployer] Deploying Test.war 11:15:15,423 WARN [TomcatModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. Deployed default/Test/1158074115142/war @ http://RI150WS311:8080/Test Examine the deploy directory. Note that it contains the application as deployed. Examine the repository\default directory. Note that it contains what I refer to as the actually running deployed application. If I were to expand this folder I would find that the WAR file has been deployed here and
[jira] Commented: (GERONIMO-2583) java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
[ http://issues.apache.org/jira/browse/GERONIMO-2583?page=comments#action_12455990 ] Rakesh Midha commented on GERONIMO-2583: I think this should also work fine, there are number of ways in which we can solve it, I think what we need to focus on is what dependencies confuses the classloader least.(reduce complexity) The criterion I was using is the one which requires least number of dependency changes. (I assumed current dependency graph is proved to be working fine and should not be changed a lot, following if it is working done change unless required ) May not the best policy all the time, but works for me :-) I hope we can find generic way to solve classloader and depenencies (for future). I need to think, so for now dont ask me what generic way i am talking about. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor --- Key: GERONIMO-2583 URL: http://issues.apache.org/jira/browse/GERONIMO-2583 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.2 Environment: Windows Xp, should be valid for all platforms Reporter: Rakesh Midha Assigned To: David Jencks Priority: Blocker Fix For: 1.2 Attachments: dependencyonlyjsr88.patch, hotdeploygbean.patch Hello This issue was discussed before in http://www.mail-archive.com/dev@geronimo.apache.org/msg28048.html and I think the patch was provided as a part of M2 migration in http://issues.apache.org/jira/browse/GERONIMO-2067#action_12423814 (It says any other issue open new JIRA, so opening this one) I downloaded latest trunk, and tried to use hot-deployer. Every time I try to use hot-deployer I get exception. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:537) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200( JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFi leClassLoader.java:298) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(J arFileClassLoader.java:250) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.geronimo.deployment.hot.DirectoryMonitor.class$(DirectoryM onitor.java:47) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:369) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct oryMonitor.java:238) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni tor.java:214) at java.lang.Thread.run(Thread.java:534) The class is in geronimo-deploy-jsr88, and hot-deploy pom.xml already shows hot-deploy to be dependent on geronimo-deploy-jsr88, which means the above class should be available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1285) Deployer does not list all modules that have been stopped
[ http://issues.apache.org/jira/browse/GERONIMO-1285?page=all ] Rakesh Midha updated GERONIMO-1285: --- Attachment: consoleprint1285.patch Patch consoleprint1285.patch prints the same for console. It prints started, stopped, uninstalled and installed module names in console. Deployer does not list all modules that have been stopped - Key: GERONIMO-1285 URL: http://issues.apache.org/jira/browse/GERONIMO-1285 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Rakesh Midha Priority: Critical Fix For: 2.0 Attachments: consoleprint1285.patch, deploytooloutput.patch When you, for example, stop the tomcat configuration, all the web apps deployed to Tomcat are stopped too. However, the deployer does not let you know this. It should list all modules that were stopped, just like it does when starting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1285) Deployer does not list all modules that have been stopped
[ http://issues.apache.org/jira/browse/GERONIMO-1285?page=all ] Rakesh Midha updated GERONIMO-1285: --- Assignee: (was: Rakesh Midha) I did both the items I was thinking to do for this JIRA. Added patch for deploy tool as well as console to prnt all the module names stopped, started, uninstalled Marking patch available, unassigning so that someone can review and commit Deployer does not list all modules that have been stopped - Key: GERONIMO-1285 URL: http://issues.apache.org/jira/browse/GERONIMO-1285 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 2.0 Attachments: consoleprint1285.patch, deploytooloutput.patch When you, for example, stop the tomcat configuration, all the web apps deployed to Tomcat are stopped too. However, the deployer does not let you know this. It should list all modules that were stopped, just like it does when starting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2621) Exception handling in Console
Exception handling in Console - Key: GERONIMO-2621 URL: http://issues.apache.org/jira/browse/GERONIMO-2621 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.0 Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 This improvement is discussed in http://comments.gmane.org/gmane.comp.java.geronimo.devel/41449 In case I get any exception or error condition in Console, the nothing is printed on web console and huge stack trace is printed on server console. Only thing done in the name of Exception handling in all the portlets is throw PortletException I somehow don't like this behavior of console. As a console user I don't want to go and see server stacktrace, if there is some error I should atleast be informed in console. I think everytime there is a error or exception in console, it should be printed in either exception page in webconsole, or in header of portlet view page. This is done to some extent in configManager and CA part of console. But not in uniform way. This is what I am proposing for Exception handling in console : 1. Create a ConsoleException.java which extends PortletException, this class will have overridden printStackTrace(PrintWriter), which will set attribute required in _ConsoleException.jsp apart from printing the stack on PrintWriter. 2. Create _ConsoleException.jsp which should be included in all portlet, this jsp will be responsible to print a short message and long stack trace. (with a toggle button to view and hide long stack trace) 3. All Portlet classes should throw ConsoleException instead of PortletException I think this will be nice and cleaner way to handle the console problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2621) Exception handling in Console
[ http://issues.apache.org/jira/browse/GERONIMO-2621?page=all ] Rakesh Midha updated GERONIMO-2621: --- Attachment: deployExp.patch As discussed in discussion thread http://comments.gmane.org/gmane.comp.java.geronimo.devel/41449 This patch provides following improvements for configManager view of console. I am supplying this patch as a sample for coming up with a guidelines to exception handling and info/warning printing. Here is what is done to handle exception in console: 1. ConsoleException.java which extends PortletException, this class will have overridden printStackTrace(PrintWriter), which will set attribute required in _ConsoleException.jsp apart from printing the stack on PrintWriter. For now logging is not used and printStackTrace() prints exception on web console and server console. 2. Create _ConsoleException.jsp which should be included in all portlet, this jsp will be responsible to print a short message and long stack trace. (with a toggle button to view and hide long stack trace and dojo dialog link). We need to select one from toggle button and dojo dialog, for now i ave included both. 4. In BasePortlet added printInfo, printWarning, printError and printFullError. Apart from console exception these methods can be used to print info, warning, error or full exception to web console. All Info and full exceptions will be printed in black, warnings in yellow and Error in red font. 5. DeploymentPortlet class throws ConsoleException instead of PortletException 6. DeploymentPortlet class also use printInfo, printWarning metods To view the effect of patch: Apply the patch Using deploy new page, try to redeploy an application which is not deployed. This will print a short exception and detailed exception. If this protocol is accepted I will provide a patch for other portlets also. thanks Exception handling in Console - Key: GERONIMO-2621 URL: http://issues.apache.org/jira/browse/GERONIMO-2621 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.0 Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: deployExp.patch This improvement is discussed in http://comments.gmane.org/gmane.comp.java.geronimo.devel/41449 In case I get any exception or error condition in Console, the nothing is printed on web console and huge stack trace is printed on server console. Only thing done in the name of Exception handling in all the portlets is throw PortletException I somehow don't like this behavior of console. As a console user I don't want to go and see server stacktrace, if there is some error I should atleast be informed in console. I think everytime there is a error or exception in console, it should be printed in either exception page in webconsole, or in header of portlet view page. This is done to some extent in configManager and CA part of console. But not in uniform way. This is what I am proposing for Exception handling in console : 1. Create a ConsoleException.java which extends PortletException, this class will have overridden printStackTrace(PrintWriter), which will set attribute required in _ConsoleException.jsp apart from printing the stack on PrintWriter. 2. Create _ConsoleException.jsp which should be included in all portlet, this jsp will be responsible to print a short message and long stack trace. (with a toggle button to view and hide long stack trace) 3. All Portlet classes should throw ConsoleException instead of PortletException I think this will be nice and cleaner way to handle the console problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2583) java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
[ http://issues.apache.org/jira/browse/GERONIMO-2583?page=all ] Rakesh Midha updated GERONIMO-2583: --- Attachment: dependencyonlyjsr88.patch Based on my last comment, here is a patch which defines dependency of geronimo-gbean-deployer on geronimo-deploy-jsr88. I think this dependency is acceptable. I tried to do complete clean build and hot deployer worked fine with this patch. Again, I must say this is a major blocker JIRA for hto deployer functionality and must be solved soon. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor --- Key: GERONIMO-2583 URL: http://issues.apache.org/jira/browse/GERONIMO-2583 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.2 Environment: Windows Xp, should be valid for all platforms Reporter: Rakesh Midha Fix For: 1.2 Attachments: dependencyonlyjsr88.patch, hotdeploygbean.patch Hello This issue was discussed before in http://www.mail-archive.com/dev@geronimo.apache.org/msg28048.html and I think the patch was provided as a part of M2 migration in http://issues.apache.org/jira/browse/GERONIMO-2067#action_12423814 (It says any other issue open new JIRA, so opening this one) I downloaded latest trunk, and tried to use hot-deployer. Every time I try to use hot-deployer I get exception. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:537) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200( JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFi leClassLoader.java:298) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(J arFileClassLoader.java:250) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.geronimo.deployment.hot.DirectoryMonitor.class$(DirectoryM onitor.java:47) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:369) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct oryMonitor.java:238) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni tor.java:214) at java.lang.Thread.run(Thread.java:534) The class is in geronimo-deploy-jsr88, and hot-deploy pom.xml already shows hot-deploy to be dependent on geronimo-deploy-jsr88, which means the above class should be available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2583) java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
[ http://issues.apache.org/jira/browse/GERONIMO-2583?page=all ] Rakesh Midha updated GERONIMO-2583: --- Patch Info: [Patch Available] Priority: Blocker (was: Major) Changing Priority to blocker, also marking patch available java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor --- Key: GERONIMO-2583 URL: http://issues.apache.org/jira/browse/GERONIMO-2583 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.2 Environment: Windows Xp, should be valid for all platforms Reporter: Rakesh Midha Priority: Blocker Fix For: 1.2 Attachments: dependencyonlyjsr88.patch, hotdeploygbean.patch Hello This issue was discussed before in http://www.mail-archive.com/dev@geronimo.apache.org/msg28048.html and I think the patch was provided as a part of M2 migration in http://issues.apache.org/jira/browse/GERONIMO-2067#action_12423814 (It says any other issue open new JIRA, so opening this one) I downloaded latest trunk, and tried to use hot-deployer. Every time I try to use hot-deployer I get exception. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:537) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200( JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFi leClassLoader.java:298) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(J arFileClassLoader.java:250) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.geronimo.deployment.hot.DirectoryMonitor.class$(DirectoryM onitor.java:47) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:369) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct oryMonitor.java:238) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni tor.java:214) at java.lang.Thread.run(Thread.java:534) The class is in geronimo-deploy-jsr88, and hot-deploy pom.xml already shows hot-deploy to be dependent on geronimo-deploy-jsr88, which means the above class should be available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2605) NPE if exporting plugin for module having dependency on module with no groupId
[ http://issues.apache.org/jira/browse/GERONIMO-2605?page=all ] Rakesh Midha updated GERONIMO-2605: --- Attachment: npeNoGroup.patch Minor change, null pointer check required before using groupId NPE if exporting plugin for module having dependency on module with no groupId -- Key: GERONIMO-2605 URL: http://issues.apache.org/jira/browse/GERONIMO-2605 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0 Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 Attachments: npeNoGroup.patch If you have an application say ABC.war which has dependency on ABC.jar and if dependency is defined without groupid like in this case dependencies dependency artifactIdABC/artifactId /dependency /dependencies You will get NPE with stacktrace: java.lang.NullPointerException at org.apache.geronimo.system.plugin.PluginInstallerGBean.processDepende ncyList(PluginInstallerGBean.java:1561) at org.apache.geronimo.system.plugin.PluginInstallerGBean.createDefaultM etadata(PluginInstallerGBean.java:1204) at org.apache.geronimo.system.plugin.PluginInstallerGBean.getPluginMetad ata(PluginInstallerGBean.java:204) at org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCG LIB$$cebc327e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2605) NPE if exporting plugin for module having dependency on module with no groupId
[ http://issues.apache.org/jira/browse/GERONIMO-2605?page=all ] Rakesh Midha updated GERONIMO-2605: --- Patch Info: [Patch Available] Description: If you have an application say ABC.war which has dependency on ABC.jar and if dependency is defined without groupid like in this case dependencies dependency artifactIdABC/artifactId /dependency /dependencies You will get NPE with stacktrace: java.lang.NullPointerException at org.apache.geronimo.system.plugin.PluginInstallerGBean.processDepende ncyList(PluginInstallerGBean.java:1561) at org.apache.geronimo.system.plugin.PluginInstallerGBean.createDefaultM etadata(PluginInstallerGBean.java:1204) at org.apache.geronimo.system.plugin.PluginInstallerGBean.getPluginMetad ata(PluginInstallerGBean.java:204) at org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCG LIB$$cebc327e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) was: If you have an application say ABC.war which has dependency on ABC.jar and if dependency is defined without groupid like in this case dependencies dependency artifactIdABC/artifactId /dependency /dependencies You will get NPE with stacktrace: java.lang.NullPointerException at org.apache.geronimo.system.plugin.PluginInstallerGBean.processDepende ncyList(PluginInstallerGBean.java:1561) at org.apache.geronimo.system.plugin.PluginInstallerGBean.createDefaultM etadata(PluginInstallerGBean.java:1204) at org.apache.geronimo.system.plugin.PluginInstallerGBean.getPluginMetad ata(PluginInstallerGBean.java:204) at org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCG LIB$$cebc327e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) Assignee: (was: Rakesh Midha) Minor change, patch attached please review and commit. NPE if exporting plugin for module having dependency on module with no groupId -- Key: GERONIMO-2605 URL: http://issues.apache.org/jira/browse/GERONIMO-2605 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0 Reporter: Rakesh Midha Fix For: 2.0 Attachments: npeNoGroup.patch If you have an application say ABC.war which has dependency on ABC.jar and if dependency is defined without groupid like in this case dependencies dependency artifactIdABC/artifactId /dependency /dependencies You will get NPE with stacktrace: java.lang.NullPointerException at org.apache.geronimo.system.plugin.PluginInstallerGBean.processDepende ncyList(PluginInstallerGBean.java:1561) at org.apache.geronimo.system.plugin.PluginInstallerGBean.createDefaultM etadata(PluginInstallerGBean.java:1204) at org.apache.geronimo.system.plugin.PluginInstallerGBean.getPluginMetad ata(PluginInstallerGBean.java:204) at org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCG LIB$$cebc327e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-795) Extend Portlet skin capabilities to support minimize and maximize
[ http://issues.apache.org/jira/browse/GERONIMO-795?page=comments#action_12454818 ] Rakesh Midha commented on GERONIMO-795: --- I liked this feature. Specially use ful in Server Logs view which has multiple portlets. I think this feature sould be activated. I am not sure why we don't have it already. May be there is some reason which I am not aware of. Anyways I am supplying the patch which will activate window state max min [nor] apart from portlet mode help [view] in the title bar. I liked this, please review and commit (if decided to accept this) Thanks Rakesh Extend Portlet skin capabilities to support minimize and maximize - Key: GERONIMO-795 URL: http://issues.apache.org/jira/browse/GERONIMO-795 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Assigned To: Rakesh Midha Fix For: Wish List Attachments: maxmin.patch Traditional portal applications support minimize and maximize as a feature on the skin in addition to help / view. We should add this feature into the admin console. It would be useful for items such as with Geronimo-794. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-795) Extend Portlet skin capabilities to support minimize and maximize
[ http://issues.apache.org/jira/browse/GERONIMO-795?page=all ] Rakesh Midha updated GERONIMO-795: -- Attachment: maxmin.patch Extend Portlet skin capabilities to support minimize and maximize - Key: GERONIMO-795 URL: http://issues.apache.org/jira/browse/GERONIMO-795 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Assigned To: Rakesh Midha Fix For: Wish List Attachments: maxmin.patch Traditional portal applications support minimize and maximize as a feature on the skin in addition to help / view. We should add this feature into the admin console. It would be useful for items such as with Geronimo-794. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-795) Extend Portlet skin capabilities to support minimize and maximize
[ http://issues.apache.org/jira/browse/GERONIMO-795?page=all ] Rakesh Midha updated GERONIMO-795: -- Patch Info: [Patch Available] Fix Version/s: 2.0 (was: Wish List) Assignee: (was: Rakesh Midha) Unassigned, market patch available and changed Fix Version to 2.0. Please review and commit Extend Portlet skin capabilities to support minimize and maximize - Key: GERONIMO-795 URL: http://issues.apache.org/jira/browse/GERONIMO-795 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Fix For: 2.0 Attachments: maxmin.patch Traditional portal applications support minimize and maximize as a feature on the skin in addition to help / view. We should add this feature into the admin console. It would be useful for items such as with Geronimo-794. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-795) Extend Portlet skin capabilities to support minimize and maximize
[ http://issues.apache.org/jira/browse/GERONIMO-795?page=all ] Rakesh Midha reassigned GERONIMO-795: - Assignee: Rakesh Midha Extend Portlet skin capabilities to support minimize and maximize - Key: GERONIMO-795 URL: http://issues.apache.org/jira/browse/GERONIMO-795 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: all Reporter: Joe Bohn Assigned To: Rakesh Midha Fix For: Wish List Traditional portal applications support minimize and maximize as a feature on the skin in addition to help / view. We should add this feature into the admin console. It would be useful for items such as with Geronimo-794. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2605) NPE if exporting plugin for module having dependency on module with no groupId
NPE if exporting plugin for module having dependency on module with no groupId -- Key: GERONIMO-2605 URL: http://issues.apache.org/jira/browse/GERONIMO-2605 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.0 Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 If you have an application say ABC.war which has dependency on ABC.jar and if dependency is defined without groupid like in this case dependencies dependency artifactIdABC/artifactId /dependency /dependencies You will get NPE with stacktrace: java.lang.NullPointerException at org.apache.geronimo.system.plugin.PluginInstallerGBean.processDepende ncyList(PluginInstallerGBean.java:1561) at org.apache.geronimo.system.plugin.PluginInstallerGBean.createDefaultM etadata(PluginInstallerGBean.java:1204) at org.apache.geronimo.system.plugin.PluginInstallerGBean.getPluginMetad ata(PluginInstallerGBean.java:204) at org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCG LIB$$cebc327e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2598) Deploy tool prints useless message if configuration start fails
Deploy tool prints useless message if configuration start fails --- Key: GERONIMO-2598 URL: http://issues.apache.org/jira/browse/GERONIMO-2598 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0 Environment: Windows XP, should be valid for all platforms Reporter: Rakesh Midha Fix For: 2.0 If you are using deploy tool, and you try to deploy or start an application which fails for start, I always give Unknown start exception Configuration default/MyPhonebookBean_openejb_artifactId/1.0/car failed to start due to the following reasons: The service EJBModule=default/MyPhonebookBean_openejb_artifactId/1.0/car,J2EEApplication =null,j2eeType=EntityBean,name=MyPhonebookBean did not start for an unknown reason In the big stack trace on server side, the deep down you see an actual error message : java.lang.IllegalArgumentException: Missing accessor for field name on class MyPhonebookBean The actual error message should be passed to deploy tool and should be printed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2598) Deploy tool prints useless message if configuration start fails
[ http://issues.apache.org/jira/browse/GERONIMO-2598?page=all ] Rakesh Midha reassigned GERONIMO-2598: -- Assignee: Rakesh Midha Deploy tool prints useless message if configuration start fails --- Key: GERONIMO-2598 URL: http://issues.apache.org/jira/browse/GERONIMO-2598 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0 Environment: Windows XP, should be valid for all platforms Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 If you are using deploy tool, and you try to deploy or start an application which fails for start, I always give Unknown start exception Configuration default/MyPhonebookBean_openejb_artifactId/1.0/car failed to start due to the following reasons: The service EJBModule=default/MyPhonebookBean_openejb_artifactId/1.0/car,J2EEApplication =null,j2eeType=EntityBean,name=MyPhonebookBean did not start for an unknown reason In the big stack trace on server side, the deep down you see an actual error message : java.lang.IllegalArgumentException: Missing accessor for field name on class MyPhonebookBean The actual error message should be passed to deploy tool and should be printed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
