Re: openejb 3.1 error on start under SnowLeopard
2010/7/30 David Blevins david.blev...@visi.com: On Jul 28, 2010, at 6:18 AM, Henri Gomez wrote: Dynamically adding a javaagent should work in java 1.6 and clearly the linux jmv supports it just fine. Seems like a VM bug in the Snow Leopard box (MacosxAttachProvider MacosxVirtualMachine) Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded at sun.tools.attach.MacosxVirtualMachine.init(MacosxVirtualMachine.java:82) at sun.t Only way to workaround this is to do it the java 1.5 way of specifying the javaagent statically on the command line. The openejb installer webapp will do that setup for the static approach, but you can also do it by hand as described above. The 'dynamic way' is just for Java 1.6 ? Right. In java 5 the only way to get a javaagent installed is on the command line and you can only enhance classes before they are loaded. In Java 6 you're *supposed* to be able to add class transformers at runtime and enhance classes even after they're loaded. Ok, I'll told my co-workers to add the agent jar in lib dir before they switch to Java 1.6 and update the run script.
Re: openejb 3.1 error on start under SnowLeopard
On Jul 28, 2010, at 6:18 AM, Henri Gomez wrote: Dynamically adding a javaagent should work in java 1.6 and clearly the linux jmv supports it just fine. Seems like a VM bug in the Snow Leopard box (MacosxAttachProvider MacosxVirtualMachine) Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded at sun.tools.attach.MacosxVirtualMachine.init(MacosxVirtualMachine.java:82) at sun.tools.attach.MacosxAttachProvider.attachVirtualMachine(MacosxAttachProvider.java:34) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:195) Yes, it seems to be Snow related. Only way to workaround this is to do it the java 1.5 way of specifying the javaagent statically on the command line. The openejb installer webapp will do that setup for the static approach, but you can also do it by hand as described above. The 'dynamic way' is just for Java 1.6 ? Right. In java 5 the only way to get a javaagent installed is on the command line and you can only enhance classes before they are loaded. In Java 6 you're *supposed* to be able to add class transformers at runtime and enhance classes even after they're loaded. -David
Re: openejb 3.1 error on start under SnowLeopard
You might be able to pass it via the JAVA_OPTS variable. Basically the goal is to copy the openejb-javaagent-3.x.x.jar into the tomcat.home/lib/ directory and make sure this java option is getting passed to the jvm: -javaagent:$CATALINA_HOME/lib/openejb-javaagent-3.x.x.jar When the agent is specified on the java command line it won't try and attach itself dynamically, which should prevent that error message you were seeing. I take a look at my Linux box and see nothing about -javaagent in startup script or openejb-javaagent-3.1.jar in tomcat6/lib/ openejb-javaagent-3.1.jar is present under tomcat6/webapps/openejb/lib/openejb-javaagent-3.1.jar The installation on the Linux box is exactly the same that on Snow but works: Here is my JAVA_OPTS : JAVA_OPTS=-Xms256m -Xmx256m -Dcom.sun.management.jmxremote.port=19952 -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Duser.language=fr -Djava.awt.headless=true From what you say, I didn't understand how it could works on Linux...
Re: openejb 3.1 error on start under SnowLeopard
On Jul 28, 2010, at 5:44 AM, Henri Gomez wrote: You might be able to pass it via the JAVA_OPTS variable. Basically the goal is to copy the openejb-javaagent-3.x.x.jar into the tomcat.home/lib/ directory and make sure this java option is getting passed to the jvm: -javaagent:$CATALINA_HOME/lib/openejb-javaagent-3.x.x.jar When the agent is specified on the java command line it won't try and attach itself dynamically, which should prevent that error message you were seeing. I take a look at my Linux box and see nothing about -javaagent in startup script or openejb-javaagent-3.1.jar in tomcat6/lib/ Right, that's the part we need to add. At least for the box that encountered the dynamic attach error. openejb-javaagent-3.1.jar is present under tomcat6/webapps/openejb/lib/openejb-javaagent-3.1.jar The installation on the Linux box is exactly the same that on Snow but works: Here is my JAVA_OPTS : JAVA_OPTS=-Xms256m -Xmx256m -Dcom.sun.management.jmxremote.port=19952 -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Duser.language=fr -Djava.awt.headless=true From what you say, I didn't understand how it could works on Linux... Dynamically adding a javaagent should work in java 1.6 and clearly the linux jmv supports it just fine. Seems like a VM bug in the Snow Leopard box (MacosxAttachProvider MacosxVirtualMachine) Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded at sun.tools.attach.MacosxVirtualMachine.init(MacosxVirtualMachine.java:82) at sun.tools.attach.MacosxAttachProvider.attachVirtualMachine(MacosxAttachProvider.java:34) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:195) Only way to workaround this is to do it the java 1.5 way of specifying the javaagent statically on the command line. The openejb installer webapp will do that setup for the static approach, but you can also do it by hand as described above. -David
Re: openejb 3.1 error on start under SnowLeopard
Dynamically adding a javaagent should work in java 1.6 and clearly the linux jmv supports it just fine. Seems like a VM bug in the Snow Leopard box (MacosxAttachProvider MacosxVirtualMachine) Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded at sun.tools.attach.MacosxVirtualMachine.init(MacosxVirtualMachine.java:82) at sun.tools.attach.MacosxAttachProvider.attachVirtualMachine(MacosxAttachProvider.java:34) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:195) Yes, it seems to be Snow related. Only way to workaround this is to do it the java 1.5 way of specifying the javaagent statically on the command line. The openejb installer webapp will do that setup for the static approach, but you can also do it by hand as described above. The 'dynamic way' is just for Java 1.6 ?
Re: openejb 3.1 error on start under SnowLeopard
On Jul 24, 2010, at 4:57 AM, Henri Gomez wrote: Note, I'm using openejb 3.1 as a webapp in Tomcat 6.0.28 Yep. The setup should copy the agent jar into the Tomcat lib dir and then mod the catalina.sh so that there's a '-javaagent:' flag passed to the vm on Tomcat startup. That will ensure the agent is there on boot and should prevent the agent from needing to attach dynamically -- which is supposed to work in java 6, but clearly having troubles. Definitely let us know how it goes. Do you means I need a special catalina.sh ? It's strange since I'm using exactly the same runtime script (not catalina.sh) on Snow and Linux boxes. You might be able to pass it via the JAVA_OPTS variable. Basically the goal is to copy the openejb-javaagent-3.x.x.jar into the tomcat.home/lib/ directory and make sure this java option is getting passed to the jvm: -javaagent:$CATALINA_HOME/lib/openejb-javaagent-3.x.x.jar When the agent is specified on the java command line it won't try and attach itself dynamically, which should prevent that error message you were seeing. -David
Re: openejb 3.1 error on start under SnowLeopard
Note, I'm using openejb 3.1 as a webapp in Tomcat 6.0.28 Yep. The setup should copy the agent jar into the Tomcat lib dir and then mod the catalina.sh so that there's a '-javaagent:' flag passed to the vm on Tomcat startup. That will ensure the agent is there on boot and should prevent the agent from needing to attach dynamically -- which is supposed to work in java 6, but clearly having troubles. Definitely let us know how it goes. Do you means I need a special catalina.sh ? It's strange since I'm using exactly the same runtime script (not catalina.sh) on Snow and Linux boxes.
Re: openejb 3.1 error on start under SnowLeopard
On Jul 21, 2010, at 12:52 AM, Henri Gomez wrote: Haven't seen this before but looks like it's related to the javaagent and dynamically attaching. Maybe try running the setup to put the agent on the command line. Note, I'm using openejb 3.1 as a webapp in Tomcat 6.0.28 Yep. The setup should copy the agent jar into the Tomcat lib dir and then mod the catalina.sh so that there's a '-javaagent:' flag passed to the vm on Tomcat startup. That will ensure the agent is there on boot and should prevent the agent from needing to attach dynamically -- which is supposed to work in java 6, but clearly having troubles. Definitely let us know how it goes. -David
Re: openejb 3.1 error on start under SnowLeopard
On Jul 16, 2010, at 3:37 AM, Henri Gomez wrote: Hi to all, I experience a very strange error on my SnowLeopard for an application using OpenEJB 3.1. This apps works well on Windows but failed on OS/X : Here is the log : at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:785) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:581) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.openejb.javaagent.Agent.dynamicLoadAgent(Agent.java:136) at org.apache.openejb.javaagent.Agent.checkInitialization(Agent.java:91) ... 47 more Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded at sun.tools.attach.MacosxVirtualMachine.init(MacosxVirtualMachine.java:82) at sun.tools.attach.MacosxAttachProvider.attachVirtualMachine(MacosxAttachProvider.java:34) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:195) ... 53 more Apache OpenEJB 3.1build: 20081009-03:31 Any idea ? Haven't seen this before but looks like it's related to the javaagent and dynamically attaching. Maybe try running the setup to put the agent on the command line. -David
