from:"Rakesh Midha"


 [ 
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 
 org.apache.coyote.http11.Http11Protocol

[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 
 org.apache.pluto.core.PortletServlet.doPost

[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

[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

2007-03-23 Thread Rakesh Midha (JIRA)

[
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

2007-03-23 Thread Rakesh Midha (JIRA)


 [ 
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

2007-03-23 Thread Rakesh Midha (JIRA)


 [ 
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.

Re: Web Console dependency viewer

2007-03-22 Thread Rakesh Midha


Hello Joe

Thanks for comments,
1. Someone need to look into safari problem because I don't have a required
resource to check the problem
2. About recursive dependencies, have a dependencies node as childnode makes
the tree huge, thats the reason I didn't implement initially. Instead what I
did is when you click on particular dependency, the node corresponding to it
is also selected which makes it easier to find. One can scroll and see the
auto selected node and keep expanding it.

This was the solution I can came up with when I was not using links, now
that I have links implemented in other views, if you think having recursive
nodes is more helpful, I can implement it. If you think recursive will be
better than highlighted and selected approach, please go ahead and open a
JIRA for this and I will make the required changes. Please note using links
may make the tree slow (but it will be better than using plain recursive
tree, plain recursive tree is a killer, i know becoz I tied it).


Thanks
Rakesh

On 3/19/07, Joe Bohn [EMAIL PROTECTED] wrote:


Rakesh,

I was just looking at the dependency viewer and I had some comments:

- There seems to still be some problems using the viewers from safari.
Is anybody looking into these problems?
- Would it be possible to follow the dependencies recursively in the
viewer?  For example, I'm looking at the dependencies of the axis car.
One of the dependencies is the j2ee-security car which in turn has a
dependency on on rmi-naming which has a dependency on j2ee-system (among
other things) etc...   However, to see these relationships I need hop
from car to car in the viewer. It would be cool if I could just continue
to expand the tree elements until a set of leaf nodes are reached.

Thanks,
Joe

Re: [BUILD] TRUNK: Failed for

2007-03-15 Thread Rakesh Midha


Hello Prasad

sounds stupid, but I got the same error yesterday but it was happening bcoz
I was sitting in wrong directory. Are you in right one?

Thanks
Rakesh

On 15 Mar 2007 09:00:45 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


Building with Maven version: 2.0.5
built with tests included
See the full build-0500.log file at
http://people.apache.org/~prasad/binaries/20070315/build-0500.log

Building trunk at
[INFO] Scanning for projects...
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] You must specify at least one goal. Try 'install'
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time:  1 second
[INFO] Finished at: Thu Mar 15 05:04:06 EDT 2007
[INFO] Final Memory: 2M/504M
[INFO]

Re: build question

2007-03-09 Thread Rakesh Midha


I find this to be working quicker for me
1. Make changes in geronimo-console-standard (I use eclipse for this)
2. go to applications\console
   if changes only in java files, use mvn -o
   if changes in JSP's also, use mvn -o clean install
3. copy
cp geronimo-console-standard\target\geronimo-
console-standard-2.0-SNAPSHOT\WEB-INF\lib\geronimo-console-standard-2.0-
SNAPSHOT.jar YOUR
BUILD\repository\org\apache\geronimo\configs\webconsole-tomcat\2.0-SNAPSHOT\webconsole-
tomcat-2.0-SNAPSHOT.car\standard.war\WEB-INF\lib\geronimo-console-standard-2.0-SNAPSHOT.j
ar
4. deploy restart org.apache.geronimo.configs
/webconsole-tomcat/2.0-SNAPSHOT/car

You are good to go to test your changes.

Thanks
Rakesh

On 3/9/07, Kanchana Welagedara [EMAIL PROTECTED] wrote:


Hi

I have tried building separate modules actually the same way what Don
has followed.Haven't you came a cross to build dependency modules(which
are complaining) while you are trying to build a particular module?After
building all the modules then figure out the target files resides on the
unzipped assembly and replace the files while server isn't running and
so on.
I agree with what Don has mentioned this is more likely a mvn
question.So there  should be a way of giving command line maven options
to build just a particular module in one shot.Hope some experts can
guide us for the sweet and shot.

Regards
Kanchana

On Thu, 2007-03-08 at 23:42 -0500, Lin Sun wrote:
 Good question and it would be great to see how others tackle this prob.
   I spent lots of time trying to figure out the best way too.:-)

 Here's one possible solution:

 1) You go to the project you made change and run mvn from there.
 2) Figure out where the target files reside on the unzipped assembly and
 replace the files while the server isn't running.  Not sure if this
 works for changes in car files, but seems to work fine for
 geronimo-axis2*.jar.  For admin console change, I think you can just
 undeploy the previous modules and deploy the updated modules while the
 server is running.  (Tried this in v1.1 and worked fine.)

 HTH Lin

 Don Hill wrote:
  Hi,
 
  I know this is probably more of a maven question but after I do a mvn
  clean install and I am working on some classes in
  applications/console/geronimo-console-standard, what is the process
that
  is followed to build just this module and then do a 'mvn install \ mvn
  -Ptools geronimo:start'
 
  I just need a better way to perform build/test cycles.
 
  Thanks.
  Don

[jira] Assigned: (GERONIMO-1945) Console's web application list does not show WARs that are deployed inside EARs

2007-03-08 Thread Rakesh Midha (JIRA)


 [ 
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.

Re: ClientCommandLine and Daemon - Changing boot approach?

2007-03-08 Thread Rakesh Midha


Hello Gianny

Oh I got it now, I think this sounds great to me.

Wait just one more question, how will you use ClientCommandLine, I mean when
geronimo-system is not in lib directory, ClientCommandLine class will be
available for direct access. Are you sure you can move
geronimo-system-2.0-SNAPSHOT.jar out of lib.

Thanks
Rakesh

On 3/8/07, Gianny Damour [EMAIL PROTECTED] wrote:


Hello Rakesh,

The dependencies which will move out of lib/ are:
backport-util-concurrent-2.2.jar
commons-jexl-1.1.jar
geronimo-common-2.0-SNAPSHOT.jar
geronimo-system-2.0-SNAPSHOT.jar
geronimo-util-2.0-SNAPSHOT.jar
ognl-2.6.9.jar
xstream-1.1.3.jar

ClientCommandLine and Daemon will still reside in geronimo-system and
they will implement org.apache.geronimo.kernel.util.Main.

The offline deployer already uses the same approach we are suggesting
to apply to ClientCommandLine and Daemon. And it is not impacted by
the change.

Thanks,
Gianny

On 08/03/2007, at 1:04 AM, Rakesh Midha wrote:

 Hello Gianny

 Question? What all dependency will you be able to move out of lib
 using this.

 Where will ClientCommandLine and Daemon implenting tje
 MainBootstrapper interface will reside.

 I am not sure what all advantages will you be able to get out of
 this redistribution. Also any thoughts on effect it may have on
 offline deployer.

 Thanks
 Rakesh

 On 3/7/07, Gianny Damour [EMAIL PROTECTED] wrote: Hi,

 Following the introduction of a potentially simpler bootstrapping
 mechanism (currently used by the deployers), we now have an
 opportunity to refactor ClientCommandLine and Daemon to leverage this
 same approach.

 The idea of the new bootstrapping mechanism is as follows:
 MainBootstrapper boots a configuration, gets from the Kernel a Main
 implementation and then delegates to it. As the Main implementation
 class can be loaded from the boot repository, rooted at repository/
 by default, the executable jar instantiating MainBootstrapper can be
 pretty generic with respect to its Class-Path entries: only geronimo-
 kernel plus its dependencies are needed.

 ClientCommandLine and Daemon could be refactored to implement the
 Main interface MainBootstrapper is looking for. With these changes,
 we should be able to move some dependencies from lib/ to repository/
 and also uniform the way CLIs are working.

 Any concerns if I do these changes?

 Thanks,
 Gianny

Re: ClientCommandLine and Daemon - Changing boot approach?

2007-03-07 Thread Rakesh Midha


Hello Gianny

Question? What all dependency will you be able to move out of lib using
this.

Where will ClientCommandLine and Daemon implenting tje MainBootstrapper
interface will reside.

I am not sure what all advantages will you be able to get out of this
redistribution. Also any thoughts on effect it may have on offline deployer.


Thanks
Rakesh

On 3/7/07, Gianny Damour [EMAIL PROTECTED] wrote:


Hi,

Following the introduction of a potentially simpler bootstrapping
mechanism (currently used by the deployers), we now have an
opportunity to refactor ClientCommandLine and Daemon to leverage this
same approach.

The idea of the new bootstrapping mechanism is as follows:
MainBootstrapper boots a configuration, gets from the Kernel a Main
implementation and then delegates to it. As the Main implementation
class can be loaded from the boot repository, rooted at repository/
by default, the executable jar instantiating MainBootstrapper can be
pretty generic with respect to its Class-Path entries: only geronimo-
kernel plus its dependencies are needed.

ClientCommandLine and Daemon could be refactored to implement the
Main interface MainBootstrapper is looking for. With these changes,
we should be able to move some dependencies from lib/ to repository/
and also uniform the way CLIs are working.

Any concerns if I do these changes?

Thanks,
Gianny

[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.

Re: Additional 'inverse' classloader view in Geronimo Console

2007-03-01 Thread Rakesh Midha


Hello Paul

I have uploaded the patch to take care of sorting. Please review and
commit/comment.

Thanks
Rakesh

On 2/27/07, Rakesh Midha [EMAIL PROTECTED] wrote:


Thanks Paul

I will look into the sorting request?

Thanks
Rakesh

On 2/26/07, Paul McMahan [EMAIL PROTECTED]  wrote:

 Yes, I chair my own little PMC but unfortunately can't seem to keep
 the committers from flaming each other.  You make it look so easy
 Matt!  :-)

 Best wishes,
 Paul

 On 2/26/07, Matt Hogstrom [EMAIL PROTECTED] wrote:
 
  On Feb 25, 2007, at 6:48 PM, Paul McMahan wrote:
 
   Thanks for the patch Rakesh!  Looks great, I committed it.  With my
   daugther sitting on my lap trying to press keys
 
  So now we know where the real work is generated from the in the
  McMahan family :)

Patchs pending for review

2007-03-01 Thread Rakesh Midha


Hello

Thanks Paul, Christopher, Vamsi, Kevan, David and others for reviewing and
commenting/commiting the patchs I submitted.

Can I ask for more, and request all the review following patchs pending for
review for quite some time.
http://issues.apache.org/jira/browse/GERONIMO-348
http://issues.apache.org/jira/browse/GERONIMO-795
http://issues.apache.org/jira/browse/GERONIMO-807
http://issues.apache.org/jira/browse/GERONIMO-1285
http://issues.apache.org/jira/browse/GERONIMO-1431
http://issues.apache.org/jira/browse/GERONIMO-1631
http://issues.apache.org/jira/browse/GERONIMO-1642
http://issues.apache.org/jira/browse/GERONIMO-1907
http://issues.apache.org/jira/browse/GERONIMO-2572
http://issues.apache.org/jira/browse/GERONIMO-2598
http://issues.apache.org/jira/browse/GERONIMO-2605
http://issues.apache.org/jira/browse/GERONIMO-2854

Few workitems pending in my TODO list depends on the review comment on above
JIRA's, hence it'll be nice to have comments on it so that I can further try
to improve the usablity aspect of deployment/hot deployment and console.

Thanks
Rakesh

Re: Additional 'inverse' classloader view in Geronimo Console

2007-02-27 Thread Rakesh Midha


Thanks Paul

I will look into the sorting request?

Thanks
Rakesh

On 2/26/07, Paul McMahan [EMAIL PROTECTED] wrote:


Yes, I chair my own little PMC but unfortunately can't seem to keep
the committers from flaming each other.  You make it look so easy
Matt!  :-)

Best wishes,
Paul

On 2/26/07, Matt Hogstrom [EMAIL PROTECTED] wrote:

 On Feb 25, 2007, at 6:48 PM, Paul McMahan wrote:

  Thanks for the patch Rakesh!  Looks great, I committed it.  With my
  daugther sitting on my lap trying to press keys

 So now we know where the real work is generated from the in the
 McMahan family :)

Re: windows build failure

2007-02-22 Thread Rakesh Midha


I did, I also tried with C:\geronimo\build0215, which gave me same error.

Removing
   dependency
 groupIdorg.apache.openejb/groupId
 artifactIdcontainer/artifactId
 version${version}/version
 typepom/type
 scopecompile/scope
   /dependency
from server-3.0-incubation-SNAPSHOT .pom solves the problem.

Thanks
Rakesh


On 2/22/07, Tim McConnell [EMAIL PROTECTED] wrote:


Hi Rakesh, could this be the infamous windows path length problem ?? Have
you
tried changing your root directory to something like C:\g instead of what
you're
using now (C:\geronimo\Copy of build0215) ??

Thanks,
Tim McConnell


Rakesh Midha wrote:
 Hello

 At last I am able to reproduce it, I am hitting this error at at corba
 builder (geronimo-corba-builder)

 Here is the relevant log





 [INFO]

-
 ---
 [INFO] Building Geronimo :: CORBA :: Builder
 [INFO]task-segment: [install]
 [INFO]

-
 ---
 [INFO] [tools:require-java-version {execution: validate-java-version}]
 [WARNING] POM for
 'org.apache.geronimo.specs:geronimo-jms_1.1_spec:pom:1.0.1:com
 pile' is invalid. It will be ignored for artifact resolution. Reason:
 Failed to
 validate POM
 [WARNING] POM for
 'org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:po
 m:1.0.1:compile' is invalid. It will be ignored for artifact resolution.
 Reason:
  Failed to validate POM
 [WARNING] POM for
 'org.apache.geronimo.specs:geronimo-ejb_2.1_spec:pom:1.0.1:com
 pile' is invalid. It will be ignored for artifact resolution. Reason:
 Failed to
 validate POM
 [INFO] [xmlbeans:xmlbeans {execution: default}]
 Time to build schema type system: 0.2 seconds
 Time to generate code: 0.952 seconds
 error: error reading C:\Documents and
 Settings\libadmin\.m2\repository\org\apach
 e\openejb\container\3.0-incubating-SNAPSHOT\container-
3.0-incubating-SNAPSHOT.po
 m; java.util.zip.ZipException: error in opening zip file
 Note: * uses or overrides a deprecated API.
 Note: Recompile with -Xlint:deprecation for details.
 1 error

 BUILD FAILED
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] XmlBeans compile failed:
  xml ErrorLoading schema file C:\geronimo\Copy of
 build0215\modules\geronimo-cor
 ba-builder\src\main\schema\corba-css-config-2.1.xsd
 xml ErrorLoading schema file C:\geronimo\Copy of
 build0215\modules\geronimo-corb
 a-builder\src\main\schema\corba-tss-config-2.1.xsd
 xml ErrorLoading config file C:\geronimo\Copy of
 build0215\modules\geronimo-corb
 a-builder\src\main\schema\xmlconfig.xml






 BTW I am using Win-XP and Maven 2.0.5

 Thanks
 Rakesh

 On 2/16/07, *Kevan Miller* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:


 On Feb 16, 2007, at 4:44 AM, Rakesh Midha wrote:

   Hello Kevan
  
   I think you said that this error is fixed after you committed the
   changes in trunk. I am working on trunk I checkout yesterday (rev
   507910). and with my bad luck I am facing the same exception even
 now.
  
   Removing
   dependency
 groupIdorg.apache.openejb/groupId
 artifactIdcontainer/artifactId
 version${version}/version
 typepom/type
 scopecompile/scope
   /dependency
   from server-3.0-incubation-SNAPSHOT.pom solves the problem.
  
   Am I missing something here.

 Strange. I don't see anything that would have unfixed my hack...

 Hmm. Maybe it needs to be excluded in a different module/config.
 Where are you hitting this error? Maybe corba enablement (or another
 change is hitting the same basic issue...).

 Anybody else seeing this?

 --kevan

[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.

Re: Additional 'inverse' classloader view in Geronimo Console

2007-02-22 Thread Rakesh Midha


Thanks, I was thinking about it but than I thought about keeping it in the
order they are loaded.

Will keep it in my TODO and will do it later (i hope that is fine)

Thanks
Rakesh

On 2/23/07, Jarek Gawor [EMAIL PROTECTED] wrote:


Hi,

I just deployed it on my machine and I love it! Thanks a ton! :)

One minor comment: can the list of classloaders be sorted
alphabetically? (in whatever view or depth)?

Thanks again,
Jarek

On 2/21/07, Rakesh Midha [EMAIL PROTECTED] wrote:
 Hello Jarek

 I have created a patch in
 http://issues.apache.org/jira/browse/GERONIMO-2854 to add
 the feature we discussed.

 Please review and comment.

 Thanks
 Rakesh




 On 2/13/07, Rakesh Midha [EMAIL PROTECTED] wrote:
  Sorry Paul
 
  I missed your last mail, when I suggested toggle.
 
  Selecting particular node when toggle happens, I am not sure about
that
 part, will have to implement it and only than I can comment :-)  No
promise
 on this one.
 
  Alright I will open a JIRA and get it done
 
  Thanks
  Rakesh
 
 
 
 
 
  On 2/13/07, Paul McMahan  [EMAIL PROTECTED] wrote:
   On 2/13/07, Rakesh Midha  [EMAIL PROTECTED] wrote:
As Jarek said, I had discussion with him before on it.
   
Well, The only concern I have is, additing too many redundent view
 will make
console uninteresting. I think we need to be careful.
   
How about this? Instead of adding new view, we add a  check or
button
 in
existing view  Show inverse tree.  Clicking or checking this
will
 inverse
the tree in same view.
  
   That's exactly what I had in mind when I mentioned toggling between
   the two types of views (inverse versus standard classloader
   hierarchy).  sorry  for not being clear about that.  My suggestion
was
   to make the toggle button sensitive to the currently selected node
in
   the classloader tree.  e.g. when the user selects a node and then
   toggles to the alternate view they see the treepaths containing the
   selected node already expanded and highlighted.
  
   
Technically, having inverse tree is not a hard work. I can take
this
 task
and get it done.
   
Thanks
Rakesh
   
   
   
   
On 2/12/07, Paul McMahan  [EMAIL PROTECTED] wrote:
 Sounds useful.  It would be great if the user could select a
node
 and
 easily toggle between the two types of views. When that node
appears
 in multiple places the tree could already have those paths
expanded
 and the nodes highlighted.

 Best wishes,
 Paul

 On 2/12/07, Jarek Gawor  [EMAIL PROTECTED] wrote:
  I was talking to Rakesh about adding additional classloader
view
 to
  the Geronimo Console and we are wondering if people have any
  comments/thoughts about it. The current view show the tree
 starting
  with the system classloader and ends with child classloaders.
 Example:
 
  A
   - B
 - F
   - C
 - F
 
  In this case, A is a parent to B and C classloaders. And B, C
are
  parent classloaders to F.
 
  Now, because Geronimo supports multi parent classloaders
sometimes
  these child classloaders can appear in multiple places in the
tree
  (e.g. F). So I proposed kind of inverse view of the
classloaders.
 For
  example, for a given child classloader, I would like to see
the
 parent
  classloaders as child nodes of the tree. Given the example
above
 the
  tree would now look like:
 
  B
   - A
 
  C
   - A
 
  F
   - B
   - C
 
  Would other people find this useful? (I know I would :))
 
  Thanks,
  Jarek

[jira] Updated: (GERONIMO-2854) Inverse Classloader view

2007-02-21 Thread Rakesh Midha (JIRA)


 [ 
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

2007-02-21 Thread Rakesh Midha (JIRA)


 [ 
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.

Re: Additional 'inverse' classloader view in Geronimo Console

2007-02-21 Thread Rakesh Midha


Hello Jarek

I have created a patch in
http://issues.apache.org/jira/browse/GERONIMO-2854to add the feature
we discussed.

Please review and comment.

Thanks
Rakesh



On 2/13/07, Rakesh Midha [EMAIL PROTECTED] wrote:


Sorry Paul

I missed your last mail, when I suggested toggle.

Selecting particular node when toggle happens, I am not sure about that
part, will have to implement it and only than I can comment :-)  No promise
on this one.

Alright I will open a JIRA and get it done

Thanks
Rakesh



On 2/13/07, Paul McMahan  [EMAIL PROTECTED] wrote:

 On 2/13/07, Rakesh Midha  [EMAIL PROTECTED] wrote:
  As Jarek said, I had discussion with him before on it.
 
  Well, The only concern I have is, additing too many redundent view
 will make
  console uninteresting. I think we need to be careful.
 
  How about this? Instead of adding new view, we add a  check or button
 in
  existing view  Show inverse tree.  Clicking or checking this will
 inverse
  the tree in same view.

 That's exactly what I had in mind when I mentioned toggling between
 the two types of views (inverse versus standard classloader
 hierarchy).  sorry  for not being clear about that.  My suggestion was
 to make the toggle button sensitive to the currently selected node in
 the classloader tree.  e.g. when the user selects a node and then
 toggles to the alternate view they see the treepaths containing the
 selected node already expanded and highlighted.

 
  Technically, having inverse tree is not a hard work. I can take this
 task
  and get it done.
 
  Thanks
  Rakesh
 
 
 
 
  On 2/12/07, Paul McMahan [EMAIL PROTECTED] wrote:
   Sounds useful.  It would be great if the user could select a node
 and
   easily toggle between the two types of views. When that node appears
   in multiple places the tree could already have those paths expanded
   and the nodes highlighted.
  
   Best wishes,
   Paul
  
   On 2/12/07, Jarek Gawor  [EMAIL PROTECTED] wrote:
I was talking to Rakesh about adding additional classloader view
 to
the Geronimo Console and we are wondering if people have any
comments/thoughts about it. The current view show the tree
 starting
with the system classloader and ends with child classloaders.
 Example:
   
A
 - B
   - F
 - C
   - F
   
In this case, A is a parent to B and C classloaders. And B, C are
parent classloaders to F.
   
Now, because Geronimo supports multi parent classloaders sometimes
these child classloaders can appear in multiple places in the tree

(e.g. F). So I proposed kind of inverse view of the classloaders.
 For
example, for a given child classloader, I would like to see the
 parent
classloaders as child nodes of the tree. Given the example above
 the
tree would now look like:
   
B
 - A
   
C
 - A
   
F
 - B
 - C
   
Would other people find this useful? (I know I would :))
   
Thanks,
Jarek

[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes

2007-02-21 Thread Rakesh Midha (JIRA)

[
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

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: windows build failure

2007-02-21 Thread Rakesh Midha


Hello

At last I am able to reproduce it, I am hitting this error at at corba
builder (geronimo-corba-builder)

Here is the relevant log


[INFO]
-
---
[INFO] Building Geronimo :: CORBA :: Builder
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [tools:require-java-version {execution: validate-java-version}]
[WARNING] POM for '
org.apache.geronimo.specs:geronimo-jms_1.1_spec:pom:1.0.1:com
pile' is invalid. It will be ignored for artifact resolution. Reason: Failed
to
validate POM
[WARNING] POM for '
org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:po
m:1.0.1:compile' is invalid. It will be ignored for artifact resolution.
Reason:
Failed to validate POM
[WARNING] POM for '
org.apache.geronimo.specs:geronimo-ejb_2.1_spec:pom:1.0.1:com
pile' is invalid. It will be ignored for artifact resolution. Reason: Failed
to
validate POM
[INFO] [xmlbeans:xmlbeans {execution: default}]
Time to build schema type system: 0.2 seconds
Time to generate code: 0.952 seconds
error: error reading C:\Documents and
Settings\libadmin\.m2\repository\org\apach
e\openejb\container\3.0-incubating-SNAPSHOT\container-
3.0-incubating-SNAPSHOT.po
m; java.util.zip.ZipException: error in opening zip file
Note: * uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error

BUILD FAILED
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] XmlBeans compile failed:
xml ErrorLoading schema file C:\geronimo\Copy of
build0215\modules\geronimo-cor
ba-builder\src\main\schema\corba-css-config-2.1.xsd
xml ErrorLoading schema file C:\geronimo\Copy of
build0215\modules\geronimo-corb
a-builder\src\main\schema\corba-tss-config-2.1.xsd
xml ErrorLoading config file C:\geronimo\Copy of
build0215\modules\geronimo-corb
a-builder\src\main\schema\xmlconfig.xml



BTW I am using Win-XP and Maven 2.0.5

Thanks
Rakesh

On 2/16/07, Kevan Miller [EMAIL PROTECTED] wrote:



On Feb 16, 2007, at 4:44 AM, Rakesh Midha wrote:

 Hello Kevan

 I think you said that this error is fixed after you committed the
 changes in trunk. I am working on trunk I checkout yesterday (rev
 507910). and with my bad luck I am facing the same exception even now.

 Removing
 dependency
   groupIdorg.apache.openejb/groupId
   artifactIdcontainer/artifactId
   version${version}/version
   typepom/type
   scopecompile/scope
 /dependency
 from server-3.0-incubation-SNAPSHOT.pom solves the problem.

 Am I missing something here.

Strange. I don't see anything that would have unfixed my hack...

Hmm. Maybe it needs to be excluded in a different module/config.
Where are you hitting this error? Maybe corba enablement (or another
change is hitting the same basic issue...).

Anybody else seeing this?

--kevan

[jira] Created: (GERONIMO-2854) Inverse Classloader view

2007-02-20 Thread Rakesh Midha (JIRA)

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.

Re: windows build failure

2007-02-16 Thread Rakesh Midha


Hello Kevan

I think you said that this error is fixed after you committed the changes in
trunk. I am working on trunk I checkout yesterday (rev 507910). and with my
bad luck I am facing the same exception even now.

Removing
   dependency
 groupIdorg.apache.openejb/groupId
 artifactIdcontainer/artifactId
 version${version}/version
 typepom/type
 scopecompile/scope
   /dependency
from server-3.0-incubation-SNAPSHOT.pom solves the problem.

Am I missing something here.

Thanks
Rakesh

On 2/5/07, Hernan Cunico [EMAIL PROTECTED] wrote:


Thanks a bunch Kevan for this workaround, I finally get to build now !

Cheers!
Hernan

Kevan Miller wrote:
 I've committed a change to trunk which should avoid this build failure.

 The change is really a work-around. The problem seems to be an xmlbeans
 bug. The work-around is to exclude the OpenEJB container. This avoids
 the container pom error and compilation failures.

 Hernan reported that he was now able to build without hacking the pom in
 his repo.

 --kevan

[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes

2007-02-15 Thread Rakesh Midha (JIRA)

[
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

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: 505174 build failure

2007-02-15 Thread Rakesh Midha


I am getting this on revision 507910

Any idea how to fix it?

Thanks
Rakesh

On 2/9/07, Ted Kirby [EMAIL PROTECTED] wrote:


Now, I get this failure:

[INFO] Executing tasks
[unzip] Expanding:
C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee
_5.ear into
C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee_5-unpacked
.ear
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error executing ant tasks

Embedded error: Error while expanding
C:\g\modules\geronimo-j2ee-builder\target\
test-ear-javaee_5.ear
C:\g\modules\geronimo-j2ee-builder\target\test-ear-javaee_5.ear (The
system cann
ot find the file specified.)

On 2/9/07, Ted Kirby [EMAIL PROTECTED] wrote:
 From head 505174, I was getting this error:
 Compiling 89 source files to
C:\g\modules\geronimo-connector\target\classes
 [INFO]

 [ERROR] BUILD FAILURE
 [INFO]

 [INFO] Compilation failure


C:\g\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\outbound\GeronimoConnectionEventListener.java:[28,34]
 package org.apache.commons.logging does not exist


C:\g\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\outbound\Gero

 I added the dependency to C:\g\modules\geronimo-connector\pom.xml, and
 was able to progress:

 dependency
 groupIdcommons-logging/groupId
 artifactIdcommons-logging/artifactId
 /dependency

Re: Additional 'inverse' classloader view in Geronimo Console

2007-02-13 Thread Rakesh Midha


Sorry Paul

I missed your last mail, when I suggested toggle.

Selecting particular node when toggle happens, I am not sure about that
part, will have to implement it and only than I can comment :-)  No promise
on this one.

Alright I will open a JIRA and get it done

Thanks
Rakesh



On 2/13/07, Paul McMahan [EMAIL PROTECTED] wrote:


On 2/13/07, Rakesh Midha [EMAIL PROTECTED] wrote:
 As Jarek said, I had discussion with him before on it.

 Well, The only concern I have is, additing too many redundent view will
make
 console uninteresting. I think we need to be careful.

 How about this? Instead of adding new view, we add a  check or button in
 existing view  Show inverse tree.  Clicking or checking this will
inverse
 the tree in same view.

That's exactly what I had in mind when I mentioned toggling between
the two types of views (inverse versus standard classloader
hierarchy).  sorry  for not being clear about that.  My suggestion was
to make the toggle button sensitive to the currently selected node in
the classloader tree.  e.g. when the user selects a node and then
toggles to the alternate view they see the treepaths containing the
selected node already expanded and highlighted.


 Technically, having inverse tree is not a hard work. I can take this
task
 and get it done.

 Thanks
 Rakesh




 On 2/12/07, Paul McMahan [EMAIL PROTECTED] wrote:
  Sounds useful.  It would be great if the user could select a node and
  easily toggle between the two types of views. When that node appears
  in multiple places the tree could already have those paths expanded
  and the nodes highlighted.
 
  Best wishes,
  Paul
 
  On 2/12/07, Jarek Gawor  [EMAIL PROTECTED] wrote:
   I was talking to Rakesh about adding additional classloader view to
   the Geronimo Console and we are wondering if people have any
   comments/thoughts about it. The current view show the tree starting
   with the system classloader and ends with child classloaders.
Example:
  
   A
- B
  - F
- C
  - F
  
   In this case, A is a parent to B and C classloaders. And B, C are
   parent classloaders to F.
  
   Now, because Geronimo supports multi parent classloaders sometimes
   these child classloaders can appear in multiple places in the tree
   (e.g. F). So I proposed kind of inverse view of the classloaders.
For
   example, for a given child classloader, I would like to see the
parent
   classloaders as child nodes of the tree. Given the example above the
   tree would now look like:
  
   B
- A
  
   C
- A
  
   F
- B
- C
  
   Would other people find this useful? (I know I would :))
  
   Thanks,
   Jarek

Re: Additional 'inverse' classloader view in Geronimo Console

2007-02-12 Thread Rakesh Midha


As Jarek said, I had discussion with him before on it.

Well, The only concern I have is, additing too many redundent view will make
console uninteresting. I think we need to be careful.

How about this? Instead of adding new view, we add a  check or button in
existing view  Show inverse tree.  Clicking or checking this will inverse
the tree in same view.

Technically, having inverse tree is not a hard work. I can take this task
and get it done.

Thanks
Rakesh



On 2/12/07, Paul McMahan [EMAIL PROTECTED] wrote:


Sounds useful.  It would be great if the user could select a node and
easily toggle between the two types of views. When that node appears
in multiple places the tree could already have those paths expanded
and the nodes highlighted.

Best wishes,
Paul

On 2/12/07, Jarek Gawor [EMAIL PROTECTED] wrote:
 I was talking to Rakesh about adding additional classloader view to
 the Geronimo Console and we are wondering if people have any
 comments/thoughts about it. The current view show the tree starting
 with the system classloader and ends with child classloaders. Example:

 A
  - B
- F
  - C
- F

 In this case, A is a parent to B and C classloaders. And B, C are
 parent classloaders to F.

 Now, because Geronimo supports multi parent classloaders sometimes
 these child classloaders can appear in multiple places in the tree
 (e.g. F). So I proposed kind of inverse view of the classloaders. For
 example, for a given child classloader, I would like to see the parent
 classloaders as child nodes of the tree. Given the example above the
 tree would now look like:

 B
  - A

 C
  - A

 F
  - B
  - C

 Would other people find this useful? (I know I would :))

 Thanks,
 Jarek

[jira] Commented: (GERONIMO-2742) Deployer cannot access libaries in shared/lib and shared/classes

2007-02-08 Thread Rakesh Midha (JIRA)


[ 
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

2007-02-08 Thread Rakesh Midha (JIRA)

[
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

--
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

2007-02-07 Thread Rakesh Midha (JIRA)

[
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

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: DayTrader newbie Starter Question

2007-02-07 Thread Rakesh Midha


According to readme
Then cd into the derby directory. Make sure the GERONIMO_HOME environment
variable is defined.  Run either createDB.bat (Windows) or createDB.sh(Unix)

and createDB.sh is there in daytrader/module/derby directory

Am I missing something?
thanks
Rakesh


On 2/7/07, Lasantha Ranaweera [EMAIL PROTECTED] wrote:


Hi All,

I have started looking at DayTrader sample application. According to the
README file there is a  createDB.sh to configure database of the
application.  I didn't  find it in the either  inside of daytrader  or
Geronimo.  Also this part is bit ambiguous to a new user like me since
it does not gives exact location of the file. :-(

How do I configure the db?

Can we create JIRA issues for such problems?

Thanks,
Lasantha

[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.

Fwd: Make changes in schema's

2007-02-06 Thread Rakesh Midha


Hello

Can someone please comment on JIRA 2660, Question is, it fine if I add
additional constaints in schema's. The reason why I ask this is adding an
additional constraints in schema files may lead to failure of some existing
user applications which doesn't follow the newly created constraints.

Sorry for asking this again.

Also I have added documentation for all the geronimo schema files, can you
please review and commit.
Please note additionally I have added license as annotation, the reason:
Some viewers shows the license if it is included as annotation (this is
required if schema is exposed through documentation produced by such
viewers)

Thanks
Rakesh
-- Forwarded message --
From: Rakesh Midha [EMAIL PROTECTED]
Date: Dec 14, 2006 12:39 PM
Subject: Make changes in schema's
To: dev@geronimo.apache.org

Hello

I have created two JIRA's
https://issues.apache.org/jira/browse/GERONIMO-2660 and
https://issues.apache.org/jira/browse/GERONIMO-2661 to make changes in
geronimo schema files.

I just wanted to check if it is OK to make changes in geronumo schema files.
The reason why I ask this is adding an additional constraints in schema
files may lead to failure of some existing user applications which doesn't
follow the newly created constraints. Although I believe they are required.

Also I was wondering if there is any specific reason for not having them
already. Please let me know if there are any, before I start making the
changes.

Please let me know your view on this. I hope I am not missing some important
point here.

Thanks
Rakesh

Trunk build server startup failure - Missing org.apache.openejb.alt.config.EjbModule

2007-02-02 Thread Rakesh Midha


Hello

I downloaded the trunk with revision 501836
I built the trunk with changes suggested by Kevan in Re: windows build
failure, the build was successful. But the server startup fails with
following message in logs:
WARN  [ConfigurationUtil] Could not load gbean org.apache.geronimo.configs
/openejb/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs
/openejb/2.0-SNAPSHOT/car,j2eeType=GBean,name=OpenEjbSystem
org.apache.geronimo.gbean.InvalidConfigurationException: Could not load
operation parameter class: name=configureApplication class=
org.apache.openejb.alt.config.EjbModule
   at org.apache.geronimo.gbean.runtime.GBeanOperation.init(
GBeanOperation.java:75)
   at org.apache.geronimo.gbean.runtime.GBeanInstance.init(
GBeanInstance.java:298)
   at org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(
BasicKernel.java:354)
   at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans
(ConfigurationUtil.java:363)
   at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(
KernelConfigurationManager.java:187)
   at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration
(SimpleConfigurationManager.java:527)
   at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration
(SimpleConfigurationManager.java:508)
   at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.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:127)
   at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(
GBeanInstance.java:820)
   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.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$227b6030.startConfiguration
(generated)
   at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:286)
   at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74)
   at org.apache.geronimo.system.main.Daemon.main(Daemon.java:366)

Looks like it is a problem with the class
org.apache.openejb.alt.config.EjbModule, the class
org.apache.openejb.config.EjbModule exists but it is expected in
openejb\alt\config

Any Idea what is wrong?

Thanks
Rakesh

Re: Trunk build server startup failure - Missing org.apache.openejb.alt.config.EjbModule

2007-02-02 Thread Rakesh Midha


Hello

Looks like while packaging assemblies the openejb cnfiguration is picked
from my m2 repository and not from newly built folder. My m2 repository had
some older version of openejb-2.0-SNAPSHOT.car configuration, hence the
error.

I manually added the openejb and openejb-deployer configuration to my build
and things work fine.

Is there a way by which i can force build to pick the configuration from by
newly created targets and not from repository.

Thanks
Rakesh

On 2/2/07, Rakesh Midha [EMAIL PROTECTED] wrote:


Hello

I downloaded the trunk with revision 501836
I built the trunk with changes suggested by Kevan in Re: windows build
failure, the build was successful. But the server startup fails with
following message in logs:
WARN  [ConfigurationUtil] Could not load gbean org.apache.geronimo.configs
/openejb/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs
/openejb/2.0-SNAPSHOT/car,j2eeType=GBean,name=OpenEjbSystem
org.apache.geronimo.gbean.InvalidConfigurationException : Could not load
operation parameter class: name=configureApplication class=
org.apache.openejb.alt.config.EjbModule
at org.apache.geronimo.gbean.runtime.GBeanOperation.init(
GBeanOperation.java:75)
at org.apache.geronimo.gbean.runtime.GBeanInstance.init(
GBeanInstance.java:298)
at org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(
BasicKernel.java:354)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(
ConfigurationUtil.java:363)
at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(
KernelConfigurationManager.java:187)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(
SimpleConfigurationManager.java:527)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration
(SimpleConfigurationManager.java:508)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.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:127)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(
GBeanInstance.java:820)
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.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$227b6030.startConfiguration(generated)
at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:286)
at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74)
at org.apache.geronimo.system.main.Daemon.main (Daemon.java:366)

Looks like it is a problem with the class
org.apache.openejb.alt.config.EjbModule, the class
org.apache.openejb.config.EjbModule exists but it is expected in
openejb\alt\config

Any Idea what is wrong?

Thanks
Rakesh

[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

Re: ClassLoader, JNDI and Dependency views in console

2007-01-16 Thread Rakesh Midha


Hello

I got the Classloader tree size reduced by 90% using the manual links in
dojo tree, for all the classloaders which occurs multiple times. These links
are loaded only when parent node is expanded.


From user perspective this will not make any difference, but internally all

the dojo functionality are changed.

This should take care of OutOfMemory and StackOverflow excception we were
getting.

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 is visible is tree loading, now it is much quicker.

I attached classloaderViewLinks.patch in
http://issues.apache.org/jira/browse/GERONIMO-2690, Please review and
commit.

Thanks
Rakesh



On 1/12/07, Paul McMahan [EMAIL PROTECTED] wrote:


It seems there is some confusion about the difference between a
Geronimo plugin and a view that plugs in to the admin console.  This
is probably due to the fact that we haven't really established the
terminology and best practices behind these new concepts yet.   To
further complicate the issue we've also alluded to future capabilities
that we want to add to the admin console to make it more pluggable.
This has made it very difficult to keep the conversation on track.

In hindsight I think it was unwise for me to bring all this up in the
context of a patch submission, a bit premature.  Plugins and their
relationship to the admin console is a pretty heavyweight concept and
probably deserves to be discussed and documented via a wiki page.
I'll go start writing something up asap to help get that discussion
underway.

So as I indicated earlier I'm +1 on committing the patch as-is and
then factoring out the views from the admin console that should be
implemented as plugins, if we decide that's the right way to go.

Best wishes,
Paul

On 1/12/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:
 I don't know if I understand your comments about ca-helper app
correctly.
 The purpose of the ca-helper app is to enable users submit certificate
 requests from web browsers (currently, from browsers that support KEYGEN
 tag), download and install issued certificates into web
browsers.  Access to
 the ca-helper application should not be controlled by geronimo-admin
realm
 and also the application exports certificates with appropriate mime type
for
 user certs and ca cert.  ca-helper is not exactly the one that plugs in
to
 Geronimo Console and becomes the CA portlet.  ca-helper app and CA
portlet
 have no common functionality.

  Vamsi


 On 1/11/07, Paul McMahan [EMAIL PROTECTED] wrote:
  On 1/10/07, Kevan Miller [EMAIL PROTECTED] wrote:
  
   Paul,
   Are you suggesting that we should start architecting the console to
   be more pluggable? Or suggesting that Rakesh rewrite these viewers?
 
  We've talked about architecting the console to be more pluggable and
  I'm definitely in favor of that.  But until that effort gets underway
  we still have the capability to make UIs pluggable into Geronimo by
  implementing them as standalone webapps.  ca-helper is a good example
  of this approach.   So really my question was whether or not Rakesh
  would consider wrappering the viewers as webapps that can then be
  installed as Geronimo plugins instead of integrating them directly
  into the console as portlets.  If that's not going to work out then
  I'm fine with Donald's suggestion of integrating in their current form
  and making them into plugins later.  The viewers are definitely a
  value contribution to Geronimo and I look forward to seeing them in
  our next release.
 
  Best wishes,
  Paul

[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

Re: Reason for sequence in XSD's

2007-01-14 Thread Rakesh Midha


David, you are right about only web app j2ee xsd using choice, and some
parts of j2ee application xsd.

As Aaron, said there are number of users reporting error which turned out to
be sequence error. Infact I myself have struggled some time because I tend
to forgot that order has to be maintained. Using choice in place of sequence
help you specially when you copy paste some elements.

Jason, about a case where it would be necessary to change the order of the
elements, there is no such requirement or case where it is necessary but I
consider sequence as an extra unrequired restrictions and people definatly
don't like redundent thinks and specially redundent restrictions

Thanks
Rakesh




On 1/15/07, Aaron Mulder [EMAIL PROTECTED] wrote:


We have seen a number of errors on the user list that turned out to be
plans with elements in the wrong order.  I'd have preferred if there
wasn't a specific order I think, but I don't feel strongly enough to
want to change all the schemas.

Thanks,
  Aaron

On 1/14/07, Jason Warner [EMAIL PROTECTED] wrote:


 
  
   Anyone got an idea, why it is so? I hope I am not missing something
   important here.
 
  I think it was mostly my preference plus a vague attempt to imitate
  the spec schemas.  It's definitely not written in stone :-)  Maybe we
  should see what other people like.

  I think it is generally easier to pick up and learn and if there is a
set
 order to the elements.  Also, I think it makes it easier to go from one
 document to another if you know where to look in the document for the
 specific element you might be looking for.  Is there a specific reason
to
 not have a set order?  I'm having trouble imagining a case where it
would be
 necessary to change the order of the elements.

[jira] Commented: (GERONIMO-2676) Web Application without required jars throws NullPointer

2007-01-12 Thread Rakesh Midha (JIRA)


[ 
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

Reason for sequence in XSD's

2007-01-12 Thread Rakesh Midha


Hello

I was just wondering if there is any specific reason for using sequence
elements in all our XSD schema's instead of choice elements.

In most of the mapped J2EE schema's choice is used. Because we are using
sequence the order of elements is fixed, and if child elements are not in
order we get invalid element exception all the time.

If choice is used instead of sequence, we can definatly avoid those
exceptions.

Anyone got an idea, why it is so? I hope I am not missing something
important here.

Thanks
Rakesh

[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts

2007-01-11 Thread Rakesh Midha (JIRA)


 [ 
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

2007-01-11 Thread Rakesh Midha (JIRA)


[ 
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

Re: ClassLoader, JNDI and Dependency views in console

2007-01-11 Thread Rakesh Midha


Hello

Paul, I will definatly provide the this viewer as a plugin, but it may take
some time. :-) kinda stuck in other activities and JIRAs. But definatly do
it.

chris, About Nullpointer, I fixed it in updated patch available in JIRA
yesterday. I had fixed it in inital patch but somehow it went only in
seprate patch and not in combined patch. Anyways its fixed. but we should
consider changing configuration to return null and not String null if
attribute is missing.

About memory problem with Classloader, I am looking into it and I think I
have an idea how to improve it. Let me implement it and pass it as another
patch over the existing patch. I think I will be able to give it in a day or
two.
Actually the classloader tree is heavy because a single classloader occures
multiple times. I and thinking if I can  load dojo tree in such a way that
such occurances can also be handled lazly. Let me fix it,I hope it will
help.

Thanks
Rakesh

On 1/12/07, Christopher M. Cardona [EMAIL PROTECTED] wrote:


Kevan Miller wrote:
 I'd like to commit what we have ATM and start addressing these issues
 (memory, ejb jar, plugability) as bug fixes/enhancements. Anybody feel
 strongly otherwise?

 --kevan

My only worry right now is the Classloader Viewer but I'm ok checking it
in as is. If nobody complains I'll go ahead and commit the patches
tomorrow night. This will give us another day for people to voice out
any concerns they have and perhaps Rakesh can squeeze in a few fixes,
enhancements, etc. ;-)

Best wishes,
chris

[jira] Commented: (GERONIMO-2689) New View for JNDI name in all the contexts

2007-01-10 Thread Rakesh Midha (JIRA)

[
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.

Re: ClassLoader, JNDI and Dependency views in console

2007-01-10 Thread Rakesh Midha


Oh I didnt see the JavaHeap space error about, let me check it out.
thanks
Rakesh

On 1/11/07, Christopher M. Cardona [EMAIL PROTECTED] wrote:


Kevan,

FYI, I updated https://issues.apache.org/jira/browse/GERONIMO-2689 to
include a patch that will fix the javascript error. You should be able
to view the new portlets at least. Please let me know if you still get
problems.

Best wishes,
chris

Kevan Miller wrote:

 On Jan 10, 2007, at 2:37 PM, Christopher M. Cardona wrote:

 Hi Rakesh,

 I was able to run the new portlets using trunk rev494034 but needed
 to change all view.jsps because I get javascript errors related to
 your calls to dojo.require(). The console uses Dojo 0.4.1 right now
 and I'm guessing you used a different version during development.
 Some widget names changed in 0.4.1.

 I'm getting a different problem this time using the ClassLoader
 viewer. I get javax.servlet.ServletException: Java heap space:

 I've seen this error, also. None of the views were working for me.
 Wasn't sure if it was a Safari issue or something else. Rakesh, can
 you take a look at these issues (javascript errors and memory
 consumption by ClassLoader viewer)?

 Paul,
 Are you suggesting that we should start architecting the console to be
 more pluggable? Or suggesting that Rakesh rewrite these viewers?

 --kevan

Re: ClassLoader, JNDI and Dependency views in console

2007-01-10 Thread Rakesh Midha


Hello Chris,

Is there some specific scenerio where you are getting java heap space error.

What I am guessing is that there can be a scenerio where classloaders are
cyclic. Is it possible, that
Classloader C1 is a parent of  Classloader C2
Classloader C2 is a parent of  Classloader C3
Classloader C3 is a parent of  Classloader C1

If it is a possible, I need to figure out a way to know it and make changes
in tree, else it will continue filling the tree in cyclic order.

Anyone please let me know if the above scenerio is allowed or not. (If it is
allowed how is classes loaded, it will continue looking for class in cyclic
order forever and never load it.)

Thanks
Rakesh

On 1/11/07, Rakesh Midha [EMAIL PROTECTED] wrote:


Oh I didnt see the JavaHeap space error about, let me check it out.
thanks
Rakesh

On 1/11/07, Christopher M. Cardona  [EMAIL PROTECTED] wrote:

 Kevan,

 FYI, I updated https://issues.apache.org/jira/browse/GERONIMO-2689 to
 include a patch that will fix the javascript error. You should be able
 to view the new portlets at least. Please let me know if you still get
 problems.

 Best wishes,
 chris

 Kevan Miller wrote:
 
  On Jan 10, 2007, at 2:37 PM, Christopher M. Cardona wrote:
 
  Hi Rakesh,
 
  I was able to run the new portlets using trunk rev494034 but needed
  to change all view.jsps because I get javascript errors related to
  your calls to dojo.require(). The console uses Dojo 0.4.1 right now
  and I'm guessing you used a different version during development.
  Some widget names changed in 0.4.1.
 
  I'm getting a different problem this time using the ClassLoader
  viewer. I get javax.servlet.ServletException: Java heap space:
 
  I've seen this error, also. None of the views were working for me.
  Wasn't sure if it was a Safari issue or something else. Rakesh, can
  you take a look at these issues (javascript errors and memory
  consumption by ClassLoader viewer)?
 
  Paul,
  Are you suggesting that we should start architecting the console to be
  more pluggable? Or suggesting that Rakesh rewrite these viewers?
 
  --kevan

[jira] Commented: (GERONIMO-720) server should give client more feedback on deployment and starting configurations.

2007-01-09 Thread Rakesh Midha (JIRA)

[
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.

[jira] Commented: (GERONIMO-720) server should give client more feedback on deployment and starting configurations.

2007-01-09 Thread Rakesh Midha (JIRA)

[
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

[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

Re: ClassLoader, JNDI and Dependency views in console

2007-01-08 Thread Rakesh Midha


Posted combined patch
https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch in
JIRA 2689

Please review and commit.

Thanks
Rakesh

On 1/8/07, Rakesh Midha [EMAIL PROTECTED] wrote:


Hello All,

Thanks for quick review,

Joe, You are right about the difference in two prespectivies, the debug
view - dependencies is to show the hirarchical dependencies of all
components, modules and it also list repository elements, whereas Config
Manager is to list the potential ramifications if a configuration is
removed.

Another major difference being the Config Manager only shows
serviceparents only, where as this view directly list the direct
dependencies as well as serviceparents.

Sachin, Prasad, David :
About
http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
it shows the static dependencies of the default server, and doens't list
any customized services, repository elements, components and configurations
deployed on server. The idea is to show the dependency information for a
particular server in its console.

I hope it clear all the points discussed here.

Chris, As you suggested I will create a single patch for all three and
post it in one of the JIRA. (Will inform once it is done).

Thanks
Rakesh


On 1/5/07, Christopher M. Cardona [EMAIL PROTECTED] wrote:

 Hi Rakesh,

 Thanks for the patches. I haven't looked at the source too but the pix
 looks good. It would be nice if you can create a combined patch for the
 3 jiras so people who wanted to check out the new debug views can use
 this as another option.

 Best wishes,
 chris

 Rakesh Midha wrote:
  Hello
 
  First of all I am sorry for being missing from the list for last few
  days, actually I have been trying to get this work item done. I kinda
  liked the idea of having ClassLoader, JNDI and Dependency views in
  console.
 
  We have discussed this before in dev list, please read the discussion
  below.
 
  I got this thing working, so I created three JIRA's, Please have a
  look at https://issues.apache.org/jira/browse/GERONIMO-2689
  https://issues.apache.org/jira/browse/GERONIMO-2690
  https://issues.apache.org/jira/browse/GERONIMO-2691
 
  These three JIRA's adds 3 view in console which shows
  1. JNDIView
  This view shows all the JNDI names binded in various componet contexts
  as well as Global context. Have a look at
 
 https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif
  to get idea of what it will show. As we can see it shows JNDI names
  for which are available at each component context level. For details
  of how this is implemented please have a look  at comments of this
 JIRA.
 
  2. ClassloaderView
  This view shows all the classloaders and classes/interfaces  loaded by
  that classloader in heirarchical fashion. Have a look at
 
 
https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gif
  to get idea of what it will show. As we can see it shows classes and
  interfaces for all the classloaders and its child classloaders. For
  details of how this is implemented please have a look  at comments of
  this JIRA.
 
  3. DependencyView
  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.. Have a look at
 
 
https://issues.apache.org/jira/secure/attachment/12348336/12348336_dependency.gif
  to get idea of what it will show. As we can see it shows dependencies
  for each component. For details of how this is implemented please have

  a look  at comments of this JIRA.
 
  This is a request that please try these patches and let me know your
  comments on it. I think I liked it and these views will definatly be
  useful for debugging purpose, and from my expierance I can tell that
  all these views are trying to facilitate solving of problems which are
  difficult to tackle otherwise.
 
  Also notice that we may like to add another section in navigation for
  debug views as shown in
 
 
https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif
  
https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif
 
  this is not implemented for now but we may do it once we agree to put
  the above views in console.
 
  Thanks in advance, please do have a look and comment.
  Rakesh
 
  On 7/20/06, *Erin Mulder* [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]  wrote:
 
  Aaron Mulder wrote:
   
http://people.apache.org/~ammulder/classloaders.pnghttp://people.apache.org/%7Eammulder/classloaders.png
   http://people.apache.org/%7Eammulder/classloaders.png
  
   However, I'm not sure how useful it will be -- it'll show you
   dependencies at the class loader level, but it won't tell you
 which
   class loaders hold a particular class or which class loader
 you're
   actually getting at some point when an error

Re: ClassLoader, JNDI and Dependency views in console

2007-01-08 Thread Rakesh Midha

I am not sure what this problem is, please let me know what version of
geronimo you are using and I will try it and let you know.

Thanks
Rakesh

On 1/8/07, Christopher M. Cardona [EMAIL PROTECTED] wrote:

Rakesh,

I tried combining your patches last time and I was able to build the
server but the it fails on startup with the following error:

[* ] 93% 20s Loading
org.apache.geronimo...19:29:49,3
12 ERROR [DeploymentFactoryImpl]
java.lang.AbstractMethodError
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
lize(JMXDeploymentManager.java:83)
at
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.ini
t(LocalDeploymentManager.java:28)
at
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
.getDeploymentManager(DeploymentFactoryImpl.java:141)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
Manager(DirectoryHotDeployer.java:317)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
toryHotDeployer.java:157)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
nstance.java:984)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
(GBeanInstanceState.java:267)
...

Not sure if I missed something. I'll give your combined patch a shot and
let you know.

Best wishes,
chris

Rakesh Midha wrote:

Posted combined patch
https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch
in JIRA 2689

Please review and commit.

Thanks
Rakesh

On 1/8/07, *Rakesh Midha* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

Hello All,

Thanks for quick review,

Joe, You are right about the difference in two prespectivies, the
debug view - dependencies is to show the hirarchical dependencies
of all components, modules and it also list repository elements,
whereas Config Manager is to list the potential ramifications if a
configuration is removed.

Another major difference being the Config Manager only shows
serviceparents only, where as this view directly list the direct
dependencies as well as serviceparents.

Sachin, Prasad, David :
About

http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
it shows the static dependencies of the default server, and
doens't list any customized services, repository elements,
components and configurations deployed on server. The idea is to
show the dependency information for a particular server in its
console.

I hope it clear all the points discussed here.

Chris, As you suggested I will create a single patch for all three
and post it in one of the JIRA. (Will inform once it is done).

Thanks
Rakesh

On 1/5/07, *Christopher M. Cardona* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

Hi Rakesh,

Thanks for the patches. I haven't looked at the source too but
the pix
looks good. It would be nice if you can create a combined
patch for the
3 jiras so people who wanted to check out the new debug views
can use
this as another option.

Best wishes,
chris

Rakesh Midha wrote:
Hello

First of all I am sorry for being missing from the list for
last few
days, actually I have been trying to get this work item done.
I kinda
liked the idea of having ClassLoader, JNDI and Dependency
views in
console.

We have discussed this before in dev list, please read the
discussion
below.

I got this thing working, so I created three JIRA's, Please
have a
look at https://issues.apache.org/jira/browse/GERONIMO-2689
https://issues.apache.org/jira/browse/GERONIMO-2690
https://issues.apache.org/jira/browse/GERONIMO-2690
https://issues.apache.org/jira/browse/GERONIMO-2691

These three JIRA's adds 3 view in console which shows
1. JNDIView
This view shows all the JNDI names binded in various componet
contexts
as well as Global context. Have a look at

https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif
to get idea of what it will show. As we can see it shows JNDI
names
for which are available at each component context level. For
details
of how this is implemented please have a look at comments of
this JIRA.

2. ClassloaderView
This view shows all the classloaders and
classes/interfaces loaded by
that classloader in heirarchical fashion. Have a look at

https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gif

Re: ClassLoader, JNDI and Dependency views in console

2007-01-08 Thread Rakesh Midha


Thanks Gianny

I didn't notice that I have recompiled openEJB, otherwise I would have
mentioned it in the comments. Thanks a lot, that saves my time :-)

Thanks
Rakesh

On 1/8/07, Gianny Damour [EMAIL PROTECTED] wrote:


Hi Chris,

I also had this problem. If you re-compile OpenEJB, then you should
be fine. In a few words, ModuleConfigurer.getModuleType has been
recently added and you are running with a EjbConfigurer which does
not define this method.

Thanks,
Gianny


On 08/01/2007, at 10:15 PM, Christopher M. Cardona wrote:

 Rakesh,

 I tried combining your patches last time and I was able to build
 the server but the it fails on startup with the following error:

 [* ] 93%  20s  Loading
 org.apache.geronimo...19:29:49,3
 12 ERROR [DeploymentFactoryImpl]
 java.lang.AbstractMethodError
at
 org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
 lize(JMXDeploymentManager.java:83)
at
 org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.ini
 t(LocalDeploymentManager.java:28)
at
 org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
 .getDeploymentManager(DeploymentFactoryImpl.java:141)
at
 org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
 Manager(DirectoryHotDeployer.java:317)
at
 org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
 toryHotDeployer.java:157)
at
 org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
 nstance.java:984)
at
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
 (GBeanInstanceState.java:267)
 ...

 Not sure if I missed something. I'll give your combined patch a
 shot and let you know.

 Best wishes,
 chris

 Rakesh Midha wrote:

 Posted combined patch https://issues.apache.org/jira/secure/
 attachment/12348488/allviews.patch in JIRA 2689

 Please review and commit.

 Thanks
 Rakesh

 On 1/8/07, *Rakesh Midha* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Hello All,

 Thanks for quick review,

 Joe, You are right about the difference in two prespectivies, the
 debug view - dependencies is to show the hirarchical dependencies
 of all components, modules and it also list repository elements,
 whereas Config Manager is to list the potential ramifications
 if a
 configuration is removed.

 Another major difference being the Config Manager only shows
 serviceparents only, where as this view directly list the direct
 dependencies as well as serviceparents.

 Sachin, Prasad, David :
 About
 http://geronimo.apache.org/maven/server/modules/geronimo-
 webservices-builder/dependencies.html
 it shows the static dependencies of the default server, and
 doens't list any customized services, repository elements,
 components and configurations deployed on server. The idea is to
 show the dependency information for a particular server in its
 console.

 I hope it clear all the points discussed here.

 Chris, As you suggested I will create a single patch for all
 three
 and post it in one of the JIRA. (Will inform once it is done).

 Thanks
 Rakesh



 On 1/5/07, *Christopher M. Cardona* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Hi Rakesh,

 Thanks for the patches. I haven't looked at the source too
 but
 the pix
 looks good. It would be nice if you can create a combined
 patch for the
 3 jiras so people who wanted to check out the new debug views
 can use
 this as another option.

 Best wishes,
 chris

 Rakesh Midha wrote:
  Hello
 
  First of all I am sorry for being missing from the list for
 last few
  days, actually I have been trying to get this work item
 done.
 I kinda
  liked the idea of having ClassLoader, JNDI and Dependency
 views in
  console.
 
  We have discussed this before in dev list, please read the
 discussion
  below.
 
  I got this thing working, so I created three JIRA's, Please
 have a
  look at https://issues.apache.org/jira/browse/GERONIMO-2689
  https://issues.apache.org/jira/browse/GERONIMO-2690
 https://issues.apache.org/jira/browse/GERONIMO-2690
  https://issues.apache.org/jira/browse/GERONIMO-2691
 
  These three JIRA's adds 3 view in console which shows
  1. JNDIView
  This view shows all the JNDI names binded in various
 componet
 contexts
  as well as Global context. Have a look at
  https://issues.apache.org/jira/secure/attachment/
 12348327/12348327_jndi.gif
  to get idea of what it will show. As we can see it shows
 JNDI
 names
  for which are available at each component context level.
 For
 details
  of how

Updated schema's in Geronimo website

2007-01-08 Thread Rakesh Midha


Can we update our website with latest Schema's. The link
http://geronimo.apache.org/schemas.html shows only 1.1 schema's, can we add
1.2 schema's also.

Thanks
Rakesh

[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

[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

[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

Re: ClassLoader, JNDI and Dependency views in console

2007-01-07 Thread Rakesh Midha


Hello All,

Thanks for quick review,

Joe, You are right about the difference in two prespectivies, the debug view
- dependencies is to show the hirarchical dependencies of all components,
modules and it also list repository elements, whereas Config Manager is to
list the potential ramifications if a configuration is removed.

Another major difference being the Config Manager only shows serviceparents
only, where as this view directly list the direct dependencies as well as
serviceparents.

Sachin, Prasad, David :
About
http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
it shows the static dependencies of the default server, and doens't list any
customized services, repository elements, components and configurations
deployed on server. The idea is to show the dependency information for a
particular server in its console.

I hope it clear all the points discussed here.

Chris, As you suggested I will create a single patch for all three and post
it in one of the JIRA. (Will inform once it is done).

Thanks
Rakesh


On 1/5/07, Christopher M. Cardona [EMAIL PROTECTED] wrote:


Hi Rakesh,

Thanks for the patches. I haven't looked at the source too but the pix
looks good. It would be nice if you can create a combined patch for the
3 jiras so people who wanted to check out the new debug views can use
this as another option.

Best wishes,
chris

Rakesh Midha wrote:
 Hello

 First of all I am sorry for being missing from the list for last few
 days, actually I have been trying to get this work item done. I kinda
 liked the idea of having ClassLoader, JNDI and Dependency views in
 console.

 We have discussed this before in dev list, please read the discussion
 below.

 I got this thing working, so I created three JIRA's, Please have a
 look at https://issues.apache.org/jira/browse/GERONIMO-2689
 https://issues.apache.org/jira/browse/GERONIMO-2690
 https://issues.apache.org/jira/browse/GERONIMO-2691

 These three JIRA's adds 3 view in console which shows
 1. JNDIView
 This view shows all the JNDI names binded in various componet contexts
 as well as Global context. Have a look at

https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif
 to get idea of what it will show. As we can see it shows JNDI names
 for which are available at each component context level. For details
 of how this is implemented please have a look  at comments of this JIRA.

 2. ClassloaderView
 This view shows all the classloaders and classes/interfaces  loaded by
 that classloader in heirarchical fashion. Have a look at

https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gif
 to get idea of what it will show. As we can see it shows classes and
 interfaces for all the classloaders and its child classloaders. For
 details of how this is implemented please have a look  at comments of
 this JIRA.

 3. DependencyView
 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.. Have a look at

https://issues.apache.org/jira/secure/attachment/12348336/12348336_dependency.gif
 to get idea of what it will show. As we can see it shows dependencies
 for each component. For details of how this is implemented please have
 a look  at comments of this JIRA.

 This is a request that please try these patches and let me know your
 comments on it. I think I liked it and these views will definatly be
 useful for debugging purpose, and from my expierance I can tell that
 all these views are trying to facilitate solving of problems which are
 difficult to tackle otherwise.

 Also notice that we may like to add another section in navigation for
 debug views as shown in

https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif
 
https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif

 this is not implemented for now but we may do it once we agree to put
 the above views in console.

 Thanks in advance, please do have a look and comment.
 Rakesh

 On 7/20/06, *Erin Mulder* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Aaron Mulder wrote:
  http://people.apache.org/~ammulder/classloaders.png
 http://people.apache.org/%7Eammulder/classloaders.png
 
  However, I'm not sure how useful it will be -- it'll show you
  dependencies at the class loader level, but it won't tell you
which
  class loaders hold a particular class or which class loader you're
  actually getting at some point when an error is uncovered.

 Also, it still needs arrows. :)

 Right now, the code for that graph produces SVG.  It would be great
to
 make it interactive so that you could drag the nodes around, click
 on a
 node to load a div that shows which classes are loaded in it, and
 maybe
 even collapse certain branches.  At JavaOne, I got a few

ClassLoader, JNDI and Dependency views in console

2007-01-05 Thread Rakesh Midha


Hello

First of all I am sorry for being missing from the list for last few days,
actually I have been trying to get this work item done. I kinda liked the
idea of having ClassLoader, JNDI and Dependency views in console.

We have discussed this before in dev list, please read the discussion below.

I got this thing working, so I created three JIRA's, Please have a look at
https://issues.apache.org/jira/browse/GERONIMO-2689
https://issues.apache.org/jira/browse/GERONIMO-2690
https://issues.apache.org/jira/browse/GERONIMO-2691

These three JIRA's adds 3 view in console which shows
1. JNDIView
This view shows all the JNDI names binded in various componet contexts as
well as Global context. Have a look at
https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gifto
get idea of what it will show. As we can see it shows JNDI names for
which are available at each component context level. For details of how this
is implemented please have a look  at comments of this JIRA.

2. ClassloaderView
This view shows all the classloaders and classes/interfaces  loaded by that
classloader in heirarchical fashion. Have a look at
https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gifto
get idea of what it will show. As we can see it shows classes and
interfaces for all the classloaders and its child classloaders. For details
of how this is implemented please have a look  at comments of this JIRA.

3. DependencyView
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.. Have a look at
https://issues.apache.org/jira/secure/attachment/12348336/12348336_dependency.gifto
get idea of what it will show. As we can see it shows dependencies
for
each component. For details of how this is implemented please have a look
at comments of this JIRA.

This is a request that please try these patches and let me know your
comments on it. I think I liked it and these views will definatly be useful
for debugging purpose, and from my expierance I can tell that all these
views are trying to facilitate solving of problems which are difficult to
tackle otherwise.

Also notice that we may like to add another section in navigation for debug
views as shown in
https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gifthis
is not implemented for now but we may do it once we agree to put the
above views in console.

Thanks in advance, please do have a look and comment.
Rakesh

On 7/20/06, Erin Mulder [EMAIL PROTECTED] wrote:


Aaron Mulder wrote:
 http://people.apache.org/~ammulder/classloaders.png

 However, I'm not sure how useful it will be -- it'll show you
 dependencies at the class loader level, but it won't tell you which
 class loaders hold a particular class or which class loader you're
 actually getting at some point when an error is uncovered.

Also, it still needs arrows. :)

Right now, the code for that graph produces SVG.  It would be great to
make it interactive so that you could drag the nodes around, click on a
node to load a div that shows which classes are loaded in it, and maybe
even collapse certain branches.  At JavaOne, I got a few simple
JavaScript behaviors working with the graph prototype, but I'm not sure
how complex it would be to add full-out drag and drop.

Perhaps you can throw the code into the sandbox so other people can
check it out and build on it?  If I recall correctly, I was careful to
make sure that all of its dependencies have Apache-compatible licenses,
(which was actually quite difficult).

Alternatively, someone could create and share a non-ASF-hosted plugin
that makes use of one of the many LGPL graph libraries out there.

Cheers,
Erin

[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
--

Attachments: common.patch, jndi.gif, jndiview2689.patch,
navigation.gif

[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