Re: Mysql driver download
Donald's changes works good for me so I guess a JIRA is not needed, ty Donald At the same location there is a 5.1.7 driver. http://mysql.mirrors.pair.com/Downloads/Connector-J/mysql-connector-java-5.1.7.zip Maybe It would be appreciated to add it to the list, keeping the 3.1.12 driver but replacing the really old 3.0.17 driver if needed ? Is there anybody out there still in need of the convenience of downloading the 3.0.17 driver from the admin console ? regards peter petersson Kevan Miller wrote: On Jun 25, 2009, at 8:43 AM, Peter Petersson wrote: Did anyone fill a JIRA about this ? (I can't find any) The mysql connector is still not downloadable from the link below. Its pointed to in the admin console db wisard on the Download a driver page. All versions of Geronimo is affected by this. I don't see a Jira. Could you create one? Drivers are available on maven central. There are also a number of newer versions. Any comments on upgrading to the latest version of connector? http://repo1.maven.org/maven2/mysql/mysql-connector-java/5.1.6/ --kevan
Re: Difference between server restart and application restart
Thanks Djencks, You are right. I tried deploying the ear from command line and faced the same issue. The thing is i am working on upgrading the geronimo server from 1.1.1 to 2.1.4 and the application is working perfectly in 1.1.1 My confusion is why this error came when app is deployed on 2.1.4 when it worked perfectly on 1.1.1? Chander -- View this message in context: http://www.nabble.com/Difference-between-server-restart-and-application-restart-tp24200158s134p24215874.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Difference between server restart and application restart
On Jun 26, 2009, at 12:02 AM, chander_bawa wrote: Thanks Djencks, You are right. I tried deploying the ear from command line and faced the same issue. The thing is i am working on upgrading the geronimo server from 1.1.1 to 2.1.4 and the application is working perfectly in 1.1.1 My confusion is why this error came when app is deployed on 2.1.4 when it worked perfectly on 1.1.1? The only reason I can think that this might work on 1.1.1 is that we had a bug in the jndi implementation in 1.1.1 that lets the lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4. If you answer the questions I asked in my previous reply I might be able to suggest a way to proceed. For instance you might be able to look the destinations up in the jca:/ global jndi context. thanks david jencks Chander -- View this message in context: http://www.nabble.com/Difference-between-server-restart-and-application-restart-tp24200158s134p24215874.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Binaries not getting deleted while un-deploying axis2-1.4.1 war from Geronimo 2.1.4
Hi, I have tried to deploy axis2 web app in geronimo 2.1.4, it is getting deployed perfectly allright. When I am trying to undeploy the axis2 webapp. I am getting the following warnings. I am not sure what is the problem. While un-deploying axis2-1.4.1 war (axis war distribution) from Geronimo 2.1.4 I get following warnings. 2009-06-26 12:15:41,985 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\activation-1.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:15:54,360 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\annogen-0.1.0.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:16:06,641 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axiom-api-1.2.7.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:16:18,937 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axiom-dom-1.2.7.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:16:31,218 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axiom-impl-1.2.7.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:16:43,483 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-adb-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:16:55,811 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-ant-plugin-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:17:08,029 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-clustering-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:17:20,310 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-corba-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:17:32,513 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-fastinfoset-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:17:44,778 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-java2wsdl-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:17:56,996 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-jaxbri-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:18:09,215 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-jaxws-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:18:21,433 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-jaxws-api-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:18:33,620 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-jibx-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:18:45,807 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-json-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:18:58,010 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-jws-api-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:19:10,228 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-kernel-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:19:22,431 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-metadata-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:19:34,618 WARN [IOUtil] D:\apps\iar\geronimo-tomcat6-javaee5-2.1.4\repository\default\axis2\1245998704986\axis2-1245998704986.war\WEB-INF\lib\axis2-mtompolicy-1.4.1.jar not deleted after 5 retries, with 0 interruptions. 2009-06-26 12:19:46,837 WARN [IOUtil]
Re: Binaries not getting deleted while un-deploying axis2-1.4.1 war from Geronimo 2.1.4
That problem exists not only when deploying axis2 webapp. It seems any packages containing third party jars in WEB-INF/lib can not be removed because of jars in use.
Re: Binaries not getting deleted while un-deploying axis2-1.4.1 war from Geronimo 2.1.4
Hi, Is it so..beacause I suppose I have deployed some of my custom web apps in geronimo 2.1.4 which does refer to many third party jars (packaged under wbe-inf/lib) and when I un-deploy those custom web-app of mine, it is undeployed smoothly, with no warning whatsoever. Anshuk Rodger wrote: That problem exists not only when deploying axis2 webapp. It seems any packages containing third party jars in WEB-INF/lib can not be removed because of jars in use. -- View this message in context: http://www.nabble.com/Binaries-not-getting-deleted-while-un-deploying-axis2-1.4.1-war-from-Geronimo-2.1.4-tp24216565s134p24216850.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Binaries not getting deleted while un-deploying axis2-1.4.1 war from Geronimo 2.1.4
I guess that it is caused by the classloader for your application is not released in some special scenarios, if possible, could you please share us your app ? Thanks ! 2009/6/26 Anshuk anshuk.palchaudh...@cognizant.com Hi, Is it so..beacause I suppose I have deployed some of my custom web apps in geronimo 2.1.4 which does refer to many third party jars (packaged under wbe-inf/lib) and when I un-deploy those custom web-app of mine, it is undeployed smoothly, with no warning whatsoever. Anshuk Rodger wrote: That problem exists not only when deploying axis2 webapp. It seems any packages containing third party jars in WEB-INF/lib can not be removed because of jars in use. -- View this message in context: http://www.nabble.com/Binaries-not-getting-deleted-while-un-deploying-axis2-1.4.1-war-from-Geronimo-2.1.4-tp24216565s134p24216850.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com. -- Ivan
Re: Binaries not getting deleted while un-deploying axis2-1.4.1 war from Geronimo 2.1.4
Hi, I am trying to deploy/undeploy axis2 version 1.4.1. You can download the the distribution from http://apache.promopeddler.com/ws/axis2/1_4_1/axis2-1.4.1-war.zip and try to deploying the same. Deploy will not be any issue. While undeploying I am facing the mentioned issue/problem. Would really appreciate if you can look into it. Anshuk Ivan Xu wrote: I guess that it is caused by the classloader for your application is not released in some special scenarios, if possible, could you please share us your app ? Thanks ! 2009/6/26 Anshuk anshuk.palchaudh...@cognizant.com Hi, Is it so..beacause I suppose I have deployed some of my custom web apps in geronimo 2.1.4 which does refer to many third party jars (packaged under wbe-inf/lib) and when I un-deploy those custom web-app of mine, it is undeployed smoothly, with no warning whatsoever. Anshuk Rodger wrote: That problem exists not only when deploying axis2 webapp. It seems any packages containing third party jars in WEB-INF/lib can not be removed because of jars in use. -- View this message in context: http://www.nabble.com/Binaries-not-getting-deleted-while-un-deploying-axis2-1.4.1-war-from-Geronimo-2.1.4-tp24216565s134p24216850.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com. -- Ivan -- View this message in context: http://www.nabble.com/Binaries-not-getting-deleted-while-un-deploying-axis2-1.4.1-war-from-Geronimo-2.1.4-tp24216565s134p24217527.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Binaries not getting deleted while un-deploying axis2-1.4.1 war from Geronimo 2.1.4
On Jun 26, 2009, at 5:40 AM, Anshuk wrote: Hi, I am trying to deploy/undeploy axis2 version 1.4.1. You can download the the distribution from http://apache.promopeddler.com/ws/axis2/1_4_1/axis2-1.4.1-war.zip and try to deploying the same. Deploy will not be any issue. While undeploying I am facing the mentioned issue/problem. Would really appreciate if you can look into it. This same problem was reported some time ago. We (Tim) developed a patch for Axis2 (it's Axis2 that is locking the files, not Geronimo). See https://issues.apache.org/jira/browse/AXIS2-4072 -- I would assume that this fix is included in their recent 1.5 release... Rather than bundling web services support in your web app, I'd recommend you use the web services supported provided by Geronimo. --kevan
Re: Difference between server restart and application restart
On Jun 26, 2009, at 3:26 AM, David Jencks wrote: On Jun 26, 2009, at 12:02 AM, chander_bawa wrote: Thanks Djencks, You are right. I tried deploying the ear from command line and faced the same issue. The thing is i am working on upgrading the geronimo server from 1.1.1 to 2.1.4 and the application is working perfectly in 1.1.1 My confusion is why this error came when app is deployed on 2.1.4 when it worked perfectly on 1.1.1? The only reason I can think that this might work on 1.1.1 is that we had a bug in the jndi implementation in 1.1.1 that lets the lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4. If you answer the questions I asked in my previous reply I might be able to suggest a way to proceed. For instance you might be able to look the destinations up in the jca:/ global jndi context. I don't think they're looking for destinations. Instead, it's looking for a TransactionManager. This same problem was reported back in April. That user reported that the oracle adapter was looking for java:comp/pm/TransactionManager. I wonder if they could be configured to look for java:/TransactionManager. I'm also wondering if throwing a RunTime exception is the appropriate behavior, in this situation. Why not a NamingException? I confess that the subtleties of JNDI are frequently lost on me... --kevan
Re: Difference between server restart and application restart
On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote: On Jun 26, 2009, at 3:26 AM, David Jencks wrote: On Jun 26, 2009, at 12:02 AM, chander_bawa wrote: Thanks Djencks, You are right. I tried deploying the ear from command line and faced the same issue. The thing is i am working on upgrading the geronimo server from 1.1.1 to 2.1.4 and the application is working perfectly in 1.1.1 My confusion is why this error came when app is deployed on 2.1.4 when it worked perfectly on 1.1.1? The only reason I can think that this might work on 1.1.1 is that we had a bug in the jndi implementation in 1.1.1 that lets the lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4. If you answer the questions I asked in my previous reply I might be able to suggest a way to proceed. For instance you might be able to look the destinations up in the jca:/ global jndi context. I don't think they're looking for destinations. Instead, it's looking for a TransactionManager. This same problem was reported back in April. That user reported that the oracle adapter was looking for java:comp/pm/TransactionManager. I wonder if they could be configured to look for java:/TransactionManager. I'm also wondering if throwing a RunTime exception is the appropriate behavior, in this situation. Why not a NamingException? I confess that the subtleties of JNDI are frequently lost on me... I think a RuntimeException might be appropriate here. there's a major logic problem in how the user is attempting to use jndi, this is not a problem due to someone forgetting to bind something in jndi. thanks david jencks --kevan
Re: Difference between server restart and application restart
On Jun 26, 2009, at 12:15 PM, David Jencks wrote: On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote: On Jun 26, 2009, at 3:26 AM, David Jencks wrote: On Jun 26, 2009, at 12:02 AM, chander_bawa wrote: Thanks Djencks, You are right. I tried deploying the ear from command line and faced the same issue. The thing is i am working on upgrading the geronimo server from 1.1.1 to 2.1.4 and the application is working perfectly in 1.1.1 My confusion is why this error came when app is deployed on 2.1.4 when it worked perfectly on 1.1.1? The only reason I can think that this might work on 1.1.1 is that we had a bug in the jndi implementation in 1.1.1 that lets the lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4. If you answer the questions I asked in my previous reply I might be able to suggest a way to proceed. For instance you might be able to look the destinations up in the jca:/ global jndi context. I don't think they're looking for destinations. Instead, it's looking for a TransactionManager. This same problem was reported back in April. That user reported that the oracle adapter was looking for java:comp/pm/TransactionManager. I wonder if they could be configured to look for java:/TransactionManager. I'm also wondering if throwing a RunTime exception is the appropriate behavior, in this situation. Why not a NamingException? I confess that the subtleties of JNDI are frequently lost on me... I think a RuntimeException might be appropriate here. there's a major logic problem in how the user is attempting to use jndi, this is not a problem due to someone forgetting to bind something in jndi. Well, not necessarily a logic error. Code may be looking for a TransactionManager in a number of jndi locations. For example, see the following OpenJPA code -- http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/ee/AutomaticManagedRuntime.java?annotate=421741pathrev=421741 They are catching Throwable, when looking for a TM in a number of locations. Don't know what Oracle is doing, here. But it sure sounds like they are treating a RuntimeException differently from a NamingException. You might argue that they should be more accepting. We've had two people report this problem. I'm just trying to see if we can/should *fix* the problem... --kevan
Re: Difference between server restart and application restart
On Jun 26, 2009, at 1:11 PM, Kevan Miller wrote: On Jun 26, 2009, at 12:15 PM, David Jencks wrote: On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote: On Jun 26, 2009, at 3:26 AM, David Jencks wrote: On Jun 26, 2009, at 12:02 AM, chander_bawa wrote: Thanks Djencks, You are right. I tried deploying the ear from command line and faced the same issue. The thing is i am working on upgrading the geronimo server from 1.1.1 to 2.1.4 and the application is working perfectly in 1.1.1 My confusion is why this error came when app is deployed on 2.1.4 when it worked perfectly on 1.1.1? The only reason I can think that this might work on 1.1.1 is that we had a bug in the jndi implementation in 1.1.1 that lets the lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4. If you answer the questions I asked in my previous reply I might be able to suggest a way to proceed. For instance you might be able to look the destinations up in the jca:/ global jndi context. I don't think they're looking for destinations. Instead, it's looking for a TransactionManager. This same problem was reported back in April. That user reported that the oracle adapter was looking for java:comp/pm/TransactionManager. I wonder if they could be configured to look for java:/TransactionManager. I'm also wondering if throwing a RunTime exception is the appropriate behavior, in this situation. Why not a NamingException? I confess that the subtleties of JNDI are frequently lost on me... I think a RuntimeException might be appropriate here. there's a major logic problem in how the user is attempting to use jndi, this is not a problem due to someone forgetting to bind something in jndi. Well, not necessarily a logic error. Code may be looking for a TransactionManager in a number of jndi locations. For example, see the following OpenJPA code -- http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/ee/AutomaticManagedRuntime.java?annotate=421741pathrev=421741 They are catching Throwable, when looking for a TM in a number of locations. Don't know what Oracle is doing, here. But it sure sounds like they are treating a RuntimeException differently from a NamingException. You might argue that they should be more accepting. We've had two people report this problem. I'm just trying to see if we can/should *fix* the problem... Ya, you're right... I guess NotContextException is probably good. thanks david jencks --kevan
