Re: Wiki Page for Samples
On Fri, 2005-10-21 at 08:22 -0400, Dave Colasurdo wrote: Claus Nyhus Christensen wrote: I have added Adventure Builder to the list (Adventure Builder is the J2EE 1.4 Blueprints application from Sun). I have this application running on Trifork T4 and JBoss, so we (Trifork) will make sure it runs on Geronimo as well. +1 Thanks!! One question... If there are unique setup/config instructions or other unique info for geronimo, will you provide these on the wiki or the adventurebuilder.dev.java.net page? Just wondering if an intermediate page is needed on the wiki. I have not given that any thought yet. I figure that besides the documentation page in the wiki, the setup will contain a Geronimo specific deployment descriptor, and an Ant file for making the installation easy. I will figure out where to place these when I am done making them :) Cheers Claus -- Claus Nyhus Christensen Software Engineer Trifork, Margrethepladsen 3, 8000 Århus C, Denmark Phone: +45 8732 8787 / http://www.trifork.com
Query related to JetSpeed and Geronimo
hi, I have Jetspeed-Fusion deployed on Geronimo. this works fine. Jetspeed provides a autoDeploy folder where i can drop JSR-168 portlets and these are picked and automatically deployed. This feature works in Tomcat. Tomcat deploys this war as a web application in webapps folder under TomCat. I am not able to get this to work in Geronimo/Tomcat or Jetty. In Geronimo its not able to pick some jars and i get ClassNotFound Exception. How do i ensure that TomCat/Jetty Classloader picks these jars. These jars are present in jetspeed web applications lib folder. They are available to jetspeed WAR but not for the wars i add to autoDeploy folder ( jaxen jar ) The portlet i add to autoDeploy folder connects to DB using a Datasource. How can i ensure this DataSource is available for the portlet thats deployed as i cant use a Geronimo specific plan. Is it possible to make the autoDeploy feature of jetspeed work on Geronimo? Thanks for any info. Regards Krishnakumar B
Re: Query related to JetSpeed and Geronimo
Krishnakumar B wrote: Is it possible to make the autoDeploy feature of jetspeed work on Geronimo? I don't know, most likely not. Geronimo doesn't provide the autodeploy feature where one could copy his deployables and expect them to be deployed. I'd like to work on the feature (but I'm almost sure that someone's declared that it's already being worked out). Does deploying JetSpeed require some artifical steps? Krishnakumar B Jacek
Re: Query related to JetSpeed and Geronimo
Jacek Laskowski wrote: Krishnakumar B wrote: Is it possible to make the autoDeploy feature of jetspeed work on Geronimo? I don't know, most likely not. Geronimo doesn't provide the autodeploy feature where one could copy his deployables and expect them to be deployed. I'd like to work on the feature (but I'm almost sure that someone's declared that it's already being worked out). AFAIK I didn't think anyone was working on it.. I submitted something very basic a few months back, but it probably can't be used directly. I still think an autodeploy feature would be awesome to have for 1.0, so if wanted to put something togather +1000 Sachin Does deploying JetSpeed require some artifical steps? Krishnakumar B Jacek
Re: The autodeploy feature in Geronimo
Jacek Laskowski wrote: Am I right that the simplest solution is to develop a GBean that would monitor a directory and hand over a deployable to a deployer? This was my thinking as well. The directory would listen for adds, modifications, and deletions. Jacek
Re: The autodeploy feature in Geronimo
Sachin Patel wrote: Jacek Laskowski wrote: Am I right that the simplest solution is to develop a GBean that would monitor a directory and hand over a deployable to a deployer? This was my thinking as well. The directory would listen for adds, modifications, and deletions. I think this may be somewhat confusing. I think when dropping in the directory, it should should deploy...then be immediately removed from the directory. IMHO, this dir should be for hot deploy only. Let the deployer decide if it should be updated or added. I think the deletions should not be done through this dir. We should use the normal undeploy capabilities of the deployer. Jacek
Re: The autodeploy feature in Geronimo
On Sun, 2005-10-23 at 16:00 -0600, Jeff Genender wrote: Sachin Patel wrote: Jacek Laskowski wrote: Am I right that the simplest solution is to develop a GBean that would monitor a directory and hand over a deployable to a deployer? This was my thinking as well. The directory would listen for adds, modifications, and deletions. I think this may be somewhat confusing. I think when dropping in the directory, it should should deploy...then be immediately removed from the directory. IMHO, this dir should be for hot deploy only. Let the deployer decide if it should be updated or added. I think the deletions should not be done through this dir. We should use the normal undeploy capabilities of the deployer. As a user it would be nice if a copy to the hot-deploy directory had the effect of an undeploy of any existing application of the same name and then reployment of the new one. This is the most common use case within development. It is also very common for the copy to the hot-deploy directory to be over a slower network. When this happens it is important to check that the file is not still being written and avoid deploying an application before the copy is complete. There is also the issue of deploying with a separate plan. In this case I suggest copying the plan first and ignoring it until the application is copied, then use the plan for the hot deployment and finally remove both the plan and the application from the hot-deploy directory. - bobby -- Bobby Abraham [EMAIL PROTECTED] Subtle Guru signature.asc Description: This is a digitally signed message part
Re: Query related to JetSpeed and Geronimo
On Oct 23, 2005, at 9:26 AM, Krishnakumar B wrote: hi, I have Jetspeed-Fusion deployed on Geronimo. this works fine. Could I ask why you are working with jetspeed 1.6 rather than 2.0? Jetspeed provides a autoDeploy folder where i can drop JSR-168 portlets and these are picked and automatically deployed. This feature works in Tomcat. Tomcat deploys this war as a web application in webapps folder under TomCat. I am not able to get this to work in Geronimo/Tomcat or Jetty. In Geronimo its not able to pick some jars and i get ClassNotFound Exception. How do i ensure that TomCat/Jetty Classloader picks these jars. These jars are present in jetspeed web applications lib folder. They are available to jetspeed WAR but not for the wars i add to autoDeploy folder ( jaxen jar ) For now I suggest you preprocess the portlet.xml and web.xml to include the portlet-wrapping-serviets directly in your web.xml. The portlet i add to autoDeploy folder connects to DB using a Datasource. How can i ensure this DataSource is available for the portlet thats deployed as i cant use a Geronimo specific plan. What is preventing you from using a geronimo plan? If you wish to avoid needing a geronimo plan for locating a resource-ref you need to make sure the resource-ref-name is identical to the connection-factory-name in a deployed datasource. For instance, in a standard geronimo installation, a resource-ref-name of SystemDatasource, looking up java:comp/env/SystemDataSource will find the datasource deployed in the system-database-plan.xml. Is it possible to make the autoDeploy feature of jetspeed work on Geronimo? I haven't looked at jetspeed autodeploy in about a year, so I'm not entirely sure how it works now. As I recall the version I looked at dynamically generated a web.xml from the supplied web.xml and portlet.xml, then called something in tomcat to deploy the modified web.xml. This is not really an appropriate architecture for geronimo IMO, at least for the jetty integration. First of all, there is currently no autodeploy at all in geronimo, and if we implement one it will be a minor add-on input to the jsr-88 deployment system. The way I imagine portlet deployment working is something like this: -- portlet deployer gets access to the web app and determines that there is a portlet.xml -- At some point in the web app ModuleBuilder, the portlet builder gets a chance to process the portlet.xml and add gbeans to the configuration representing the servlets wrapping the portlets. -- these gbeans are started along with the other gbeans in the configuration. This would work more or less directly for jetty. IIUC the tomcat integration is still allowing the tomcat deployment code to process the web.xml itself. Therefore a tomcat portlet deployer would probably have to modify the web.xml rather than configuring gbeans directly. However, I think ejb web service deployment does not involve any web.xml processing, so it may be possible to do something analogous for portlets and configure them directly. Thanks! Please keep us informed of your progress and problems you may encounter. david jencks Thanks for any info. Regards Krishnakumar B
Re: loading gbeans
On Oct 22, 2005, at 7:05 PM, Sachin Patel wrote:
Is there a way to load a loaded configuration's gbeans' without
starting the configuration? I'm basically wanting query a gbean's
persistent attribute value on a loaded but not started configuration.
Looking through the code the configuration's gbeans are loaded only
after its containing configuration is started
kernel.startGBean(configName);
kernel.invoke(configName, loadGBeans, new Object[] {attributeStore},
new String[] {ManageableAttributeStore.class.getName()});
This makes sense, but I'm wondering if there is an alternate way to
get the gbeans attribute values on an already deployed and serialized
configuration.
I don't think we can do better at this point. There is no limit on the
complexity of attribute values, and the only restriction other than
serializablitly is that classes used must be loadable by the
configuration's classloader. This classloader is only available when
the configuration gbean is started.
If you're willing to use the kernel methods directly rather than the
methods on ConfigurationManager (I recommend sticking to using the
ConfigurationManager) you could pass your own ManageableAttributeStore
in that gets all the gbean datas and return an empty list. This would
result in you getting the gbean datas and no gbeans getting loaded.
Why do you want to avoid loading the gbeans?
thanks
david jencks
???
Sachin
[jira] Created: (GERONIMO-1104) org.openejb.proxy.CglibEJBProxyFactory$NoOverrideCallbackFilter should implement equals() and hashcode() methods
org.openejb.proxy.CglibEJBProxyFactory$NoOverrideCallbackFilter should implement equals() and hashcode() methods Key: GERONIMO-1104 URL: http://issues.apache.org/jira/browse/GERONIMO-1104 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M4, 1.0-M5 Reporter: John Sisson Priority: Trivial Fix For: 1.0 The NoOverrideCallbackFilter inner class should implement equals() and hashcode() methods, as a result of the discussions on cglib in GERONIMO-1062. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1104) org.openejb.proxy.CglibEJBProxyFactory$NoOverrideCallbackFilter should implement equals() and hashcode() methods
[ http://issues.apache.org/jira/browse/GERONIMO-1104?page=all ] John Sisson updated GERONIMO-1104: -- Attachment: org.openejb.proxy.CglibEJBProxyFactory.java.patch Patch attached to be reviewed applied for OpenEJB. org.openejb.proxy.CglibEJBProxyFactory$NoOverrideCallbackFilter should implement equals() and hashcode() methods Key: GERONIMO-1104 URL: http://issues.apache.org/jira/browse/GERONIMO-1104 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M4, 1.0-M5 Reporter: John Sisson Priority: Trivial Fix For: 1.0 Attachments: org.openejb.proxy.CglibEJBProxyFactory.java.patch The NoOverrideCallbackFilter inner class should implement equals() and hashcode() methods, as a result of the discussions on cglib in GERONIMO-1062. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1104) org.openejb.proxy.CglibEJBProxyFactory$NoOverrideCallbackFilter should implement equals() and hashcode() methods
[ http://issues.apache.org/jira/browse/GERONIMO-1104?page=all ] David Jencks reassigned GERONIMO-1104: -- Assign To: David Jencks org.openejb.proxy.CglibEJBProxyFactory$NoOverrideCallbackFilter should implement equals() and hashcode() methods Key: GERONIMO-1104 URL: http://issues.apache.org/jira/browse/GERONIMO-1104 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M4, 1.0-M5 Reporter: John Sisson Assignee: David Jencks Priority: Trivial Fix For: 1.0 Attachments: org.openejb.proxy.CglibEJBProxyFactory.java.patch The NoOverrideCallbackFilter inner class should implement equals() and hashcode() methods, as a result of the discussions on cglib in GERONIMO-1062. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1104) org.openejb.proxy.CglibEJBProxyFactory$NoOverrideCallbackFilter should implement equals() and hashcode() methods
[ http://issues.apache.org/jira/browse/GERONIMO-1104?page=all ] David Jencks closed GERONIMO-1104: -- Resolution: Fixed Applied, Checking in modules/core/src/java/org/openejb/proxy/CglibEJBProxyFactory.java; new revision: 1.4; previous revision: 1.3 org.openejb.proxy.CglibEJBProxyFactory$NoOverrideCallbackFilter should implement equals() and hashcode() methods Key: GERONIMO-1104 URL: http://issues.apache.org/jira/browse/GERONIMO-1104 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M4, 1.0-M5 Reporter: John Sisson Assignee: David Jencks Priority: Trivial Fix For: 1.0 Attachments: org.openejb.proxy.CglibEJBProxyFactory.java.patch The NoOverrideCallbackFilter inner class should implement equals() and hashcode() methods, as a result of the discussions on cglib in GERONIMO-1062. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1105) org.apache.geronimo.axis.client.NoOverrideCallbackFilter should implement should implement equals() and hashcode() methods
org.apache.geronimo.axis.client.NoOverrideCallbackFilter should implement should implement equals() and hashcode() methods -- Key: GERONIMO-1105 URL: http://issues.apache.org/jira/browse/GERONIMO-1105 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: John Sisson Assigned to: John Sisson Priority: Trivial Fix For: 1.0 The NoOverrideCallbackFilter class should implement equals() and hashcode() methods, as a result of the discussions on cglib in GERONIMO-1062. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1062) OpenEJB client leaks memory on each JNDI lookup. Get OutOfMemoryException after a few thousand lookups
[ http://issues.apache.org/jira/browse/GERONIMO-1062?page=comments#action_12349905 ] David Jencks commented on GERONIMO-1062: Patch to the callback filter was applied for GERONIMO-1104. I don't understand the concern over loading a single proxy instance permanently in an application that doesn't manage its own classloaders. Such an application will also load the ejb home and remote interfaces from the same classloader and these interfaces will be equally permanent, even if the ejb is only used once during startup. If you need to release the proxy, you can load the ejb interfaces in a disposable classloader as well, and get rid of all of them at once. OpenEJB client leaks memory on each JNDI lookup. Get OutOfMemoryException after a few thousand lookups --- Key: GERONIMO-1062 URL: http://issues.apache.org/jira/browse/GERONIMO-1062 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M5, 1.0-M4 Environment: Windows XP j2sdk1.4.2_08 Reporter: John Sisson Priority: Critical Fix For: 1.0 Attachments: AllObjects.zip, CgLibProxyFactory.java.patch, apps.zip I have a standalone java application that uses OpenEJB's JNDI implementation (org.openejb.client.RemoteInitialContextFactory ). It appears that each JNDI lookup of an EJB is leaking memory and it looks like it is related to cglib. I have attached to this JIRA a simple EJB and standalone java client application that can be used to reproduce the problem. Extract the zip file to the geronimo\sandbox directory cd sandbox\echoTest maven -o deploy the echoTest.ear file in the sandbox\echoTest\target directory cd sandbox\echoTestStandaloneClient maven -o cd target java -jar echoTestStandaloneClient-0.1-SNAPSHOT.jar The console will be updated with the number of lookups performed. E.G here are a few examples with different JVM settings: C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClientset JAVA_HOME=C:\Program Files\Java\j2sdk1.4.2_08 C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClient%JAVA_HOME%\bin\java.exe -jar target\echoTestStandaloneClient-0. 1-SNAPSHOT.jar After 0 lookups: delta: 1,911,024, free: 1,911,024, used: 120,592, total: 2,031,616, max: 66,650,112 After 1000 lookups: delta: 417,040, free: 2,328,064, used: 2,603,520, total: 4,931,584, max: 66,650,112 After 2000 lookups: delta: 1,765,304, free: 4,093,368, used: 5,151,304, total: 9,244,672, max: 66,650,112 After 3000 lookups: delta: 1,759,288, free: 5,852,656, used: 7,303,696, total: 13,156,352, max: 66,650,112 After 4000 lookups: delta: 2,182,664, free: 8,035,320, used: 10,081,288, total: 18,116,608, max: 66,650,112 After 5000 lookups: delta: 1,579,184, free: 9,614,504, used: 11,574,104, total: 21,188,608, max: 66,650,112 Lookups performed: 5432 Exception in thread main net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetExce ption--null at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:304) at org.openejb.client.CgLibProxyFactory.newProxyInstance(CgLibProxyFactory.java:92) at org.openejb.client.CgLibProxyFactory.newProxyInstance(CgLibProxyFactory.java:81) at org.openejb.client.ProxyManager.newProxyInstance(ProxyManager.java:90) at org.openejb.client.EJBHomeHandler.createEJBHomeProxy(EJBHomeHandler.java:106) at org.openejb.client.JNDIContext.createEJBHomeProxy(JNDIContext.java:212) at org.openejb.client.JNDIContext.lookup(JNDIContext.java:245) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.acme.EchoTestStandaloneClient.testLookup(EchoTestStandaloneClient.java:87) at org.acme.EchoTestStandaloneClient.main(EchoTestStandaloneClient.java:76) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219) ... 11 more Caused by: java.lang.OutOfMemoryError If I try this on JDK 1.5.0_05, it is worse as the JVM becomes unresponsive and uses a lot of CPU and I have to kill the JVM: C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClientjava -jar target\echoTestStandaloneClient-0.1-SNAPSHOT.jar After 0 lookups: delta: 1,863,336, free: 1,863,336, used: 168,280, total:
[jira] Closed: (GERONIMO-1105) org.apache.geronimo.axis.client.NoOverrideCallbackFilter should implement should implement equals() and hashcode() methods
[ http://issues.apache.org/jira/browse/GERONIMO-1105?page=all ] John Sisson closed GERONIMO-1105: - Resolution: Fixed Applied.. Revision: 327895 Author: jsisson Date: 10:57:34 AM, Monday, 24 October 2005 Message: GERONIMO-1105 implement equals() and hashcode() methods as a result of the discussions on cglib in for GERONIMO#1062, to keep implementations of CallbackFilter consistent. Modified : /geronimo/trunk/modules/axis/src/java/org/apache/geronimo/axis/client/NoOverrideCallbackFilter.java org.apache.geronimo.axis.client.NoOverrideCallbackFilter should implement should implement equals() and hashcode() methods -- Key: GERONIMO-1105 URL: http://issues.apache.org/jira/browse/GERONIMO-1105 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: John Sisson Assignee: John Sisson Priority: Trivial Fix For: 1.0 The NoOverrideCallbackFilter class should implement equals() and hashcode() methods, as a result of the discussions on cglib in GERONIMO-1062. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1062) OpenEJB client leaks memory on each JNDI lookup. Get OutOfMemoryException after a few thousand lookups
[ http://issues.apache.org/jira/browse/GERONIMO-1062?page=all ] David Jencks closed GERONIMO-1062: -- Resolution: Fixed Assign To: David Jencks Further examination reveals that the patch for this bug is for a different file than 1104. Applied: Checking in src/java/org/openejb/client/CgLibProxyFactory.java; new revision: 1.6; previous revision: 1.5 OpenEJB client leaks memory on each JNDI lookup. Get OutOfMemoryException after a few thousand lookups --- Key: GERONIMO-1062 URL: http://issues.apache.org/jira/browse/GERONIMO-1062 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M5, 1.0-M4 Environment: Windows XP j2sdk1.4.2_08 Reporter: John Sisson Assignee: David Jencks Priority: Critical Fix For: 1.0 Attachments: AllObjects.zip, CgLibProxyFactory.java.patch, apps.zip I have a standalone java application that uses OpenEJB's JNDI implementation (org.openejb.client.RemoteInitialContextFactory ). It appears that each JNDI lookup of an EJB is leaking memory and it looks like it is related to cglib. I have attached to this JIRA a simple EJB and standalone java client application that can be used to reproduce the problem. Extract the zip file to the geronimo\sandbox directory cd sandbox\echoTest maven -o deploy the echoTest.ear file in the sandbox\echoTest\target directory cd sandbox\echoTestStandaloneClient maven -o cd target java -jar echoTestStandaloneClient-0.1-SNAPSHOT.jar The console will be updated with the number of lookups performed. E.G here are a few examples with different JVM settings: C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClientset JAVA_HOME=C:\Program Files\Java\j2sdk1.4.2_08 C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClient%JAVA_HOME%\bin\java.exe -jar target\echoTestStandaloneClient-0. 1-SNAPSHOT.jar After 0 lookups: delta: 1,911,024, free: 1,911,024, used: 120,592, total: 2,031,616, max: 66,650,112 After 1000 lookups: delta: 417,040, free: 2,328,064, used: 2,603,520, total: 4,931,584, max: 66,650,112 After 2000 lookups: delta: 1,765,304, free: 4,093,368, used: 5,151,304, total: 9,244,672, max: 66,650,112 After 3000 lookups: delta: 1,759,288, free: 5,852,656, used: 7,303,696, total: 13,156,352, max: 66,650,112 After 4000 lookups: delta: 2,182,664, free: 8,035,320, used: 10,081,288, total: 18,116,608, max: 66,650,112 After 5000 lookups: delta: 1,579,184, free: 9,614,504, used: 11,574,104, total: 21,188,608, max: 66,650,112 Lookups performed: 5432 Exception in thread main net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetExce ption--null at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:304) at org.openejb.client.CgLibProxyFactory.newProxyInstance(CgLibProxyFactory.java:92) at org.openejb.client.CgLibProxyFactory.newProxyInstance(CgLibProxyFactory.java:81) at org.openejb.client.ProxyManager.newProxyInstance(ProxyManager.java:90) at org.openejb.client.EJBHomeHandler.createEJBHomeProxy(EJBHomeHandler.java:106) at org.openejb.client.JNDIContext.createEJBHomeProxy(JNDIContext.java:212) at org.openejb.client.JNDIContext.lookup(JNDIContext.java:245) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.acme.EchoTestStandaloneClient.testLookup(EchoTestStandaloneClient.java:87) at org.acme.EchoTestStandaloneClient.main(EchoTestStandaloneClient.java:76) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219) ... 11 more Caused by: java.lang.OutOfMemoryError If I try this on JDK 1.5.0_05, it is worse as the JVM becomes unresponsive and uses a lot of CPU and I have to kill the JVM: C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClientjava -jar target\echoTestStandaloneClient-0.1-SNAPSHOT.jar After 0 lookups: delta: 1,863,336, free: 1,863,336, used: 168,280, total: 2,031,616, max: 66,650,112 After 1000 lookups: delta: 482,408, free: 2,345,744, used: 2,684,144, total: 5,029,888, max: 66,650,112 After 2000 lookups: delta: 1,865,064, free: 4,210,808, used: 5,267,336, total: 9,478,144, max: 66,650,112 After 3000 lookups: delta: 2,116,488,
[jira] Commented: (GERONIMO-1062) OpenEJB client leaks memory on each JNDI lookup. Get OutOfMemoryException after a few thousand lookups
[ http://issues.apache.org/jira/browse/GERONIMO-1062?page=comments#action_12349909 ] John Sisson commented on GERONIMO-1062: --- I agree with David's comments, so ignore my previous concerns :-) A negative side effect of what I was suggesting would have been cglib regenerating the proxy classes over and over (which was what was happening before the patch), which is bad from a performance point of view. So this issue is resolved. OpenEJB client leaks memory on each JNDI lookup. Get OutOfMemoryException after a few thousand lookups --- Key: GERONIMO-1062 URL: http://issues.apache.org/jira/browse/GERONIMO-1062 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M5, 1.0-M4 Environment: Windows XP j2sdk1.4.2_08 Reporter: John Sisson Assignee: David Jencks Priority: Critical Fix For: 1.0 Attachments: AllObjects.zip, CgLibProxyFactory.java.patch, apps.zip I have a standalone java application that uses OpenEJB's JNDI implementation (org.openejb.client.RemoteInitialContextFactory ). It appears that each JNDI lookup of an EJB is leaking memory and it looks like it is related to cglib. I have attached to this JIRA a simple EJB and standalone java client application that can be used to reproduce the problem. Extract the zip file to the geronimo\sandbox directory cd sandbox\echoTest maven -o deploy the echoTest.ear file in the sandbox\echoTest\target directory cd sandbox\echoTestStandaloneClient maven -o cd target java -jar echoTestStandaloneClient-0.1-SNAPSHOT.jar The console will be updated with the number of lookups performed. E.G here are a few examples with different JVM settings: C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClientset JAVA_HOME=C:\Program Files\Java\j2sdk1.4.2_08 C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClient%JAVA_HOME%\bin\java.exe -jar target\echoTestStandaloneClient-0. 1-SNAPSHOT.jar After 0 lookups: delta: 1,911,024, free: 1,911,024, used: 120,592, total: 2,031,616, max: 66,650,112 After 1000 lookups: delta: 417,040, free: 2,328,064, used: 2,603,520, total: 4,931,584, max: 66,650,112 After 2000 lookups: delta: 1,765,304, free: 4,093,368, used: 5,151,304, total: 9,244,672, max: 66,650,112 After 3000 lookups: delta: 1,759,288, free: 5,852,656, used: 7,303,696, total: 13,156,352, max: 66,650,112 After 4000 lookups: delta: 2,182,664, free: 8,035,320, used: 10,081,288, total: 18,116,608, max: 66,650,112 After 5000 lookups: delta: 1,579,184, free: 9,614,504, used: 11,574,104, total: 21,188,608, max: 66,650,112 Lookups performed: 5432 Exception in thread main net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetExce ption--null at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:304) at org.openejb.client.CgLibProxyFactory.newProxyInstance(CgLibProxyFactory.java:92) at org.openejb.client.CgLibProxyFactory.newProxyInstance(CgLibProxyFactory.java:81) at org.openejb.client.ProxyManager.newProxyInstance(ProxyManager.java:90) at org.openejb.client.EJBHomeHandler.createEJBHomeProxy(EJBHomeHandler.java:106) at org.openejb.client.JNDIContext.createEJBHomeProxy(JNDIContext.java:212) at org.openejb.client.JNDIContext.lookup(JNDIContext.java:245) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.acme.EchoTestStandaloneClient.testLookup(EchoTestStandaloneClient.java:87) at org.acme.EchoTestStandaloneClient.main(EchoTestStandaloneClient.java:76) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219) ... 11 more Caused by: java.lang.OutOfMemoryError If I try this on JDK 1.5.0_05, it is worse as the JVM becomes unresponsive and uses a lot of CPU and I have to kill the JVM: C:\OpenSourceJava\geronimo\trunk\sandbox\echoTestStandaloneClientjava -jar target\echoTestStandaloneClient-0.1-SNAPSHOT.jar After 0 lookups: delta: 1,863,336, free: 1,863,336, used: 168,280, total: 2,031,616, max: 66,650,112 After 1000 lookups: delta: 482,408, free: 2,345,744, used: 2,684,144, total: 5,029,888, max: 66,650,112 After 2000 lookups: delta: 1,865,064, free: 4,210,808, used: 5,267,336,
Re: OSGi Container in Geronimo
On Fri, 2005-10-21 at 15:38 -0700, Eishay Smith wrote: Dain, Did you think about the communication with client side? How do you think an OSGi bundle that lives inside an Eclipse environment will communicate with another bundle that resides in Geronimo? Will it have a standard way, using some J2EE protocol (RMI/IIOP or SOAP for example) with a proxy on the server side that stands in between (EJB or WS), or just a your problem - what ever you like? If you want to do it with SOAP we (Axis2 folks) will be glad to help .. this'll be a good chance to integrate Axis2 to Geronimo as well. Sanjiva.
Re: loading gbeans
David Jencks wrote:
On Oct 22, 2005, at 7:05 PM, Sachin Patel wrote:
Is there a way to load a loaded configuration's gbeans' without
starting the configuration? I'm basically wanting query a gbean's
persistent attribute value on a loaded but not started configuration.
Looking through the code the configuration's gbeans are loaded only
after its containing configuration is started
kernel.startGBean(configName);
kernel.invoke(configName, loadGBeans, new Object[] {attributeStore},
new String[] {ManageableAttributeStore.class.getName()});
This makes sense, but I'm wondering if there is an alternate way to
get the gbeans attribute values on an already deployed and serialized
configuration.
I don't think we can do better at this point. There is no limit on the
complexity of attribute values, and the only restriction other than
serializablitly is that classes used must be loadable by the
configuration's classloader. This classloader is only available when
the configuration gbean is started.
If you're willing to use the kernel methods directly rather than the
methods on ConfigurationManager (I recommend sticking to using the
ConfigurationManager) you could pass your own ManageableAttributeStore
in that gets all the gbean datas and return an empty list. This would
result in you getting the gbean datas and no gbeans getting loaded.
Why do you want to avoid loading the gbeans?
Well I was looking into the shutdown script a little this weekend and we
need to be able to shutdown the correct kernel if multiple server
instances are running. In order to do so we need to get the correct
port number from the RMIRegistry gbean in order to be able to connect to
and shutdown the correct kernel. So I launched a temp kernel and loaded
the RMINamingConfiguration. From there, starting that configuration
fails since the RMIRegistry gbean's port number is already in use. So I
was looking a way to bypass starting the configuration and to just be
able to load that particular gbean and get its port attribute. From
there I can put togather the correct uri, create a kernel delegate and
shut it down.
thanks
david jencks
???
Sachin
[jira] Created: (GERONIMO-1106) Upgrade to CgLib maintenance release 2.1_03
Upgrade to CgLib maintenance release 2.1_03 --- Key: GERONIMO-1106 URL: http://issues.apache.org/jira/browse/GERONIMO-1106 Project: Geronimo Type: Task Components: general, OpenEJB Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.0 CgLib maintenance release 2.1_03 is available on http://sourceforge.net/projects/cglib/ . I have sent a mail to [EMAIL PROTECTED] asking for it to be uploaded to maven repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1107) Upgrade HOWL from version 0.1.8 to version 0.1.11
Upgrade HOWL from version 0.1.8 to version 0.1.11 - Key: GERONIMO-1107 URL: http://issues.apache.org/jira/browse/GERONIMO-1107 Project: Geronimo Type: Task Components: transaction manager Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.0 See http://howl.objectweb.org/ for details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Comments regarding Geronimo on HOWL project page http://howl.objectweb.org/
The HOWL project page says: The Apache Geronimo project has plans to integrate JOTM, and has integrated the HOWL logger with an interim transaction manager that is being used until JOTM recovery functionality is available. Have plans changed? If so, we should ask that this be updated to reflect reality so people are not mislead. Comments? Thanks, John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
Re: OSGi Container in Geronimo
Great! We still need to figure out few things, but communication is indeed one of the centrals. Do you have a specific pattern/workflow in mind? Thanks, Eishay Sanjiva Weerawarana [EMAIL PROTECTED] To ce.lkdev@geronimo.apache.org cc 10/23/2005 08:00 [EMAIL PROTECTED] PMSubject Re: OSGi Container in Geronimo Please respond to dev On Fri, 2005-10-21 at 15:38 -0700, Eishay Smith wrote: Dain, Did you think about the communication with client side? How do you think an OSGi bundle that lives inside an Eclipse environment will communicate with another bundle that resides in Geronimo? Will it have a standard way, using some J2EE protocol (RMI/IIOP or SOAP for example) with a proxy on the server side that stands in between (EJB or WS), or just a your problem - what ever you like? If you want to do it with SOAP we (Axis2 folks) will be glad to help .. this'll be a good chance to integrate Axis2 to Geronimo as well. Sanjiva.
