Re: Access Database Pool with Only Persistence.xml
I don't see any very complete docs on the subject with a quick look. There is some info here on how to set up jta-datasource in persistence.xml: http://cwiki.apache.org/GMOxDOC21/datasource-connectionfactory-mdb-and-jpa.html You also need to make sure the module/plugin with the datasource is in the ancestors of your app, typically by listing it directly as a dependency of your app in the geronimo plan. Maven can help you with this: http://cwiki.apache.org/GMOxDOC21/constructing-a-special-purpose-server-using-maven.html Hope this helps and inspires someone to make more complete, concise, and non-eclipse jpa documentation. thanks david jencks On Jul 29, 2008, at 5:29 PM, kurzweil4 wrote: Is it in any way possible to access a database pool defined on the server merely by specifying a value in persistence.xml as with other application servers? Currently, whatever value I put causes a deployment failure. I see that other people have the same problem as me all the time but I have not found a definitive answer. If I understand correctly, Geronimo requires a bunch of configuration files? Is it not possible to access the data source with just the JEE standard files? If I am required to create all of these config files, that kind of rules out Geronimo for me because I have no generator to make them. I saw the deployment plan generator in the console, but this is for an EAR not a WAR. Thanks in advance for any help. -- View this message in context: http://www.nabble.com/Access-Database-Pool-with-Only-Persistence.xml-tp18723940s134p18723940.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[BUILD] trunk: Failed for Revision: 680925
Geronimo Revision: 680925 built with tests included
See the full build-0300.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080730/build-0300.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080730
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 43 minutes 51 seconds
[INFO] Finished at: Wed Jul 30 03:53:22 EDT 2008
[INFO] Final Memory: 409M/1008M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080730/logs-0300-tomcat/test.log
Assembly: jetty
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080730/logs-0300-jetty/test.log
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: jetty
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty6-javaee5/2.2-SNAPSHOT/geronimo-jetty6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:42.506
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 31 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:03.044)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.755)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:18.800)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:07.864)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:25.731) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:51.553)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:50.289)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:50.533)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:43.216)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:31.328)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:28.982)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:33.498)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb
Re: Could not load custaddr/ejbs/TestBean.class - When Deploy Ear
Thanks for the test application. I could deploy your application, but I didn't get the error message: Could not load custaddr/ejbs/TestBeanLocal.class (it's not custaddr/ejbs/TestBean.class in your sample) Also I added the following to index.jsp and it works fine, that means the classloader of web module can load the ejb classes. <%custaddr.ejbs.TestBeanLocal abc = null;%> Because you are using the JSF implementation of ICESoft and there is no class com.icesoft.faces.util.event.servlet.ContextEventRepeater in your sample package. So I'm not sure whether the @EJB in your managed bean works fine. -- Yun Feng - Original Message From: kurzweil4 <[EMAIL PROTECTED]> To: dev@geronimo.apache.org Sent: Wednesday, July 30, 2008 1:41:15 PM Subject: Re: Could not load custaddr/ejbs/TestBean.class - When Deploy Ear Yun, You can download the file here: http://jira.icefaces.org/secure/attachment/11147/JSF_ICEFaces.zip It contains the EAR and all of the project files. You will need this plan to deploy it with, and the pool name defined on the server (and perhaps anything else that I am not aware that I need): http://geronimo.apache.org/xml/ns/j2ee/web-1.1";> TestInjectWeb console.dbpool PostgresDS /TestInjectWeb jdbc/MyDataSource PostgresDS Thank you for your help! Kurzweil4 YunFeng Ma wrote: > > IIUC, EAR application and it's children Web modules have different > classloaders, but the parent classloader of the children Web modules > classloaders is the ERA application classloader which can load the classes > in ejb jars. So I can not understand why your web module can not load the > ejb classes. It will be useful to find out the answer if you can attach > your application. :-) > > -- Yun Feng > > > > - Original Message > From: kurzweil4 <[EMAIL PROTECTED]> > To: dev@geronimo.apache.org > Sent: Wednesday, July 30, 2008 10:39:50 AM > Subject: Could not load custaddr/ejbs/TestBean.class - When Deploy Ear > > > > When I deploy my EAR, I get the following error message: > > Could not load custaddr/ejbs/TestBean.class > > This error occurs when Geronimo is trying to deploy the WAR, which > references custaddr/ejbs/TestBean.class in the EJB-JAR. > > The EJB-JAR installs, but it has no Session beans in the JNDI viewer. > > Any ideas? > > Thanks > -- > View this message in context: > http://www.nabble.com/Could-not-load-custaddr-ejbs-TestBean.class---When-Deploy-Ear-tp18725148s134p18725148.html > Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. > > > > -- View this message in context: http://www.nabble.com/Could-not-load-custaddr-ejbs-TestBean.class---When-Deploy-Ear-tp18725148s134p18726429.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMODEVTOOLS-429) Testcase failures in org.apache.geronimo.st.core plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618292#action_12618292 ] Ted Kirby commented on GERONIMODEVTOOLS-429: If only the test case needs ordering, not the working code, it would probably be better to have the test case do the ordering. > Testcase failures in org.apache.geronimo.st.core plugin > --- > > Key: GERONIMODEVTOOLS-429 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-429 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.2 >Reporter: Tim McConnell >Assignee: Tim McConnell > Fix For: 2.1.2 > > > --- > Test set: org.apache.geronimo.st.core.internal.DependencyHelperTest > --- > Tests run: 6, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 0.656 sec <<< > FAILURE! > testMultipleParents(org.apache.geronimo.st.core.internal.DependencyHelperTest) > Time elapsed: 0.078 sec <<< FAILURE! > junit.framework.AssertionFailedError: expected:<[EMAIL PROTECTED]> but > was:<[EMAIL PROTECTED]> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > org.apache.geronimo.st.core.internal.DependencyHelperTest.testMultipleParents(DependencyHelperTest.java:268) > at > org.apache.geronimo.st.core.internal.DependencyHelperTest.testMultipleParents(DependencyHelperTest.java:268) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > testMultipleChildrenAndParents1(org.apache.geronimo.st.core.internal.DependencyHelperTest) > Time elapsed: 0.062 sec <<< FAILURE! > junit.framework.AssertionFailedError: expected:<[EMAIL PROTECTED]> but > was:<[EMAIL PROTECTED]> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > org.apache.geronimo.st.core.internal.DependencyHelperTest.testMultipleChildrenAndParents1(DependencyHelperTest.java:334) > at > org.apache.geronimo.st.core.internal.DependencyHelperTest.testMultipleChildrenAndParents1(DependencyHelperTest.java:334) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(Deleg
Re: Could not load custaddr/ejbs/TestBean.class - When Deploy Ear
Yun, Thank you so much for you effort. One thing I forgot to mention is the version of Geronimo I am deploying to: geronimo-tomcat6-javaee5-2.1.1 Is this the same version you are deploying to? So with the same EAR and plan, you don't get the error message. I will have to try again. About the class com.icesoft.faces.util.event.servlet.ContextEventRepeater, should I be referencing this somewhere in my project? Thanks Again, Kurzweil4 YunFeng Ma wrote: > > Thanks for the test application. I could deploy your application, but I > didn't get the error message: > Could not load custaddr/ejbs/TestBeanLocal.class (it's not > custaddr/ejbs/TestBean.class in your sample) > Also I added the following to index.jsp and it works fine, that means the > classloader of web module can load the ejb classes. > <%custaddr.ejbs.TestBeanLocal abc = null;%> > > Because > you are using the JSF implementation of ICESoft and there is no class > com.icesoft.faces.util.event.servlet.ContextEventRepeater in your > sample package. So I'm not sure whether the @EJB in your managed bean > works fine. > > -- Yun Feng > > > - Original Message > From: kurzweil4 <[EMAIL PROTECTED]> > To: dev@geronimo.apache.org > Sent: Wednesday, July 30, 2008 1:41:15 PM > Subject: Re: Could not load custaddr/ejbs/TestBean.class - When Deploy Ear > > > Yun, > > You can download the file here: > > http://jira.icefaces.org/secure/attachment/11147/JSF_ICEFaces.zip > > It contains the EAR and all of the project files. > > You will need this plan to deploy it with, and the pool name defined on > the > server (and perhaps anything else that I am not aware that I need): > > > xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1";> > > > TestInjectWeb > > > > console.dbpool > PostgresDS > > > > > /TestInjectWeb > > > > > jdbc/MyDataSource > PostgresDS > > > > Thank you for your help! > Kurzweil4 > > > YunFeng Ma wrote: >> >> IIUC, EAR application and it's children Web modules have different >> classloaders, but the parent classloader of the children Web modules >> classloaders is the ERA application classloader which can load the >> classes >> in ejb jars. So I can not understand why your web module can not load the >> ejb classes. It will be useful to find out the answer if you can attach >> your application. :-) >> >> -- Yun Feng >> >> >> >> - Original Message >> From: kurzweil4 <[EMAIL PROTECTED]> >> To: dev@geronimo.apache.org >> Sent: Wednesday, July 30, 2008 10:39:50 AM >> Subject: Could not load custaddr/ejbs/TestBean.class - When Deploy Ear >> >> >> >> When I deploy my EAR, I get the following error message: >> >> Could not load custaddr/ejbs/TestBean.class >> >> This error occurs when Geronimo is trying to deploy the WAR, which >> references custaddr/ejbs/TestBean.class in the EJB-JAR. >> >> The EJB-JAR installs, but it has no Session beans in the JNDI viewer. >> >> Any ideas? >> >> Thanks >> -- >> View this message in context: >> http://www.nabble.com/Could-not-load-custaddr-ejbs-TestBean.class---When-Deploy-Ear-tp18725148s134p18725148.html >> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. >> >> >> >> > > -- > View this message in context: > http://www.nabble.com/Could-not-load-custaddr-ejbs-TestBean.class---When-Deploy-Ear-tp18725148s134p18726429.html > Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. > > > > -- View this message in context: http://www.nabble.com/Could-not-load-custaddr-ejbs-TestBean.class---When-Deploy-Ear-tp18725148s134p18731816.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Reducing the dojo footprint in Geronimo
On Jul 29, 2008, at 3:36 PM, Joseph Leong wrote: Hi everyone, So i'm building a little widget piece to run on AG and i've come to the point of deciding whether i'm going to incorporate any (if) dojo/ dojox components into it. I know we've had varying discussions about reducing the dojo footprint. To summarize i believe the only thing we've agreed on so far is removing the unncessary /tests , but i'm wondering if the community had anymore input on keeping dojox around? To summarize it is my understanding these are the choices suggested so far: 1) Removing Dojo from AG and having users include their own optimized Dojo files for their apps. The downside is that we may be inefficient in aggregating multiple copies of Dojo. 2) Leave Dojo support in AG as is now. We can safely rely on the fact that their will be no duplicate instances of dojo for those who use it, but we must now rely on having that dojo overhead even for users who don't utilize it. 3) Creating a slim version of Dojo to support the features relying on it in AG, thus allowing users who want to demonstrate fundamental dojo features to utilize it - but however we incur the maintenance overhead of creating new builds of Dojo to incorporate with AG releases as new fundamental AG components with Dojo are included. Personally, I feel the functionality subset of DojoX captures a lot of what this Web2.0 era is looking for. Although it may make more sense to go with option 3, now, i feel it's only a matter of time before we switch over to option 2. To provide the community with a better grasp of what the DojoX functionalities are goto: http://dojocampus.org/explorer/#Dojox and you'll find yourself quite surprised at how innovative and integrated these technologies are influencing your favorite sites. Thanks a lot for picking this up, again, Joseph. Personally, I'd like to see the Dojo footprint within Geronimo reduced. It's pretty simple to make a full-Dojo plugin that users can install, if they want a full Dojo library available. IMO, this can meet the needs of Dojo users (as described in #2). Can you help me understand the maintenance overhead of creating a customized Dojo library? If #3 is high maintenance, I may need to reconsider. --kevan
Javamail OSGi definitions
I was looking at the OSGi information that's used for the javamail jars, and it appears to be currently incomplete, and possibly even incorrect, if I'm interpreting the information correct. Javamail is split between a spec component, which is in the Geronimo specs tree, and a provider component that has its own source tree and build. The specs component builds a specs jar. The javamail component builds a provider jar (which has a dependency on the specs jar) and a mail uber-jar that merges the spec and provider jars into a single jar file. Currently, only the javamail specs is building with OSGi information in the manifest. Here is the manifest from the jar file: Manifest-Version: 1.0 Built-By: Rick McGuire Created-By: Apache Maven Bundle Plugin Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt Import-Package: javax.activation,javax.mail;version="1.4",javax.mail.e vent;version="1.4",javax.mail.internet;version="1.4",javax.mail.searc h;version="1.4",javax.mail.util;version="1.4" Bnd-LastModified: 1214586504570 Export-Package: javax.mail.search;uses:="javax.mail";version="1.4",jav ax.mail.util;uses:="javax.mail.internet,javax.activation";version="1. 4",javax.mail.event;uses:="javax.mail";version="1.4",javax.mail.inter net;uses:="javax.activation,javax.mail,org.apache.geronimo.mail.util" ;version="1.4",javax.mail;uses:="javax.mail.search,javax.mail.event,j avax.activation";version="1.4" Bundle-Version: 1.4.0.SNAPSHOT Bundle-Name: geronimo-javamail_1.4_spec Bundle-Description: Javamail 1.4 Specification Build-Jdk: 1.5.0_11 Private-Package: org.apache.geronimo.mail.handlers;version="1.4-SNAPSH OT",org.apache.geronimo.mail.util;version="1.4-SNAPSHOT" Bundle-DocURL: http://www.apache.org Bundle-ManifestVersion: 2 Bundle-Vendor: The Apache Software Foundation Bundle-SymbolicName: org.apache.geronimo.specs.geronimo-javamail_1.4_s pec Implementation-Title: Apache Geronimo Tool: Bnd-0.0.227 Implementation-Version: 1.4-SNAPSHOT The classes in org.apache.geronimo.mail.handlers and org.apache.geronimo.mail.util are defined as Private-Package. I'm not sure this is correct, since the Providers jar file uses those classes. The merged uber-jar can probably make these private, but I think the provider requirement would not allow this. Am I correct here? Neither the javamail provider jar or mail uber-jar have any OSGi bundle information. I suspect it needs to be added, since any application that wishes to use javamail for more than just the javax.mail.* classes (e.g., to send mail) would need to pull in either the provider bundle or the mail uber jar bundle. I'd like to take a stab at fixing this, but I'm not really what the requirements are for the OSGi enablement. Do we have a documented set of instructions anywhere? Rick
[jira] Created: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
Database pool unusable after database unavailable for awhile Key: GERONIMO-4222 URL: https://issues.apache.org/jira/browse/GERONIMO-4222 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0.2 Environment: RedHat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 Reporter: David Frahm I have frequent trouble with my database pool to an AS/400. The database is taken down every night for backup, and at least once a week the connection pool is unusable after the database comes back up. Restarting the connection pool makes everything work again. We are new to Geronimo/WAS-CE -- just this one app on one server -- so I don't have anything to compare to. However, we have had this same issue with a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. Configuration Info Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) Pool Min Size: 0 Pool Max Size: 100 Blocking Timeout: 5000 Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Frahm updated GERONIMO-4222: -- Environment: Red Hat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 was: RedHat Enterprise Linux Server v5.2 WAS-CE v2.0.0.1, based on Geronimo v2.0.2 > Database pool unusable after database unavailable for awhile > > > Key: GERONIMO-4222 > URL: https://issues.apache.org/jira/browse/GERONIMO-4222 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.2 > Environment: Red Hat Enterprise Linux Server v5.2 > WAS-CE v2.0.0.1, based on Geronimo v2.0.2 >Reporter: David Frahm > > I have frequent trouble with my database pool to an AS/400. The database is > taken down every night for backup, and at least once a week the connection > pool is unusable after the database comes back up. Restarting the connection > pool makes everything work again. > We are new to Geronimo/WAS-CE -- just this one app on one server -- so I > don't have anything to compare to. However, we have had this same issue with > a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are > several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. > Configuration Info > Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) > Pool Min Size: 0 > Pool Max Size: 100 > Blocking Timeout: 5000 > Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618401#action_12618401 ] Thad West commented on GERONIMO-4222: - We are running Geronimo 2.0.2 connecting to MySQL v5 The default for MySQL is to close a connection after 8 hours of inactivity (overnight for us). Here are the details: http://dev.mysql.com/doc/refman/5.0/en/gone-away.html For testing purposes, you could change the time limit by setting the wait_timeout variable when you start mysql. http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html So...MySQL invalidates the connection, but Geronimo keeps it in the pool. As soon as you get one of these connections and try to use it, kablammo! > Database pool unusable after database unavailable for awhile > > > Key: GERONIMO-4222 > URL: https://issues.apache.org/jira/browse/GERONIMO-4222 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.2 > Environment: Red Hat Enterprise Linux Server v5.2 > WAS-CE v2.0.0.1, based on Geronimo v2.0.2 >Reporter: David Frahm > > I have frequent trouble with my database pool to an AS/400. The database is > taken down every night for backup, and at least once a week the connection > pool is unusable after the database comes back up. Restarting the connection > pool makes everything work again. > We are new to Geronimo/WAS-CE -- just this one app on one server -- so I > don't have anything to compare to. However, we have had this same issue with > a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are > several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. > Configuration Info > Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) > Pool Min Size: 0 > Pool Max Size: 100 > Blocking Timeout: 5000 > Idle Timeout: 15 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Help!]G2.1.2 branch build failure saying "org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2" not found in any repository
After checked out 2.1.2 branch, want to build it from scratch, issue command: mvn install -e Then the build error saying org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2 could not found, ask me to download and install it manually. Why? Maven version tried 2.0.9, 2.0.7, 2.0.5, all same problem. Please help! thanks! Best regards, Forrest
[jira] Commented: (GERONIMO-4221) car file for daytrader module is not generated correctly via c-m-p
[ https://issues.apache.org/jira/browse/GERONIMO-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618403#action_12618403 ] David Jencks commented on GERONIMO-4221: I've thought about this for a long time and see 2 possible ways forward: 1. run the c-m-p 3 times and have it produce the 3 car files indenpendently. This is really wasteful since the c-m-p already does build all the needed car files, it just doesn't move 2 of them into the local maven repo. 2. use maven classifiers for the app clients rather than having completely separate artifact names. (2) seems like it would probably involve more changes to geronimo internals but it also fits much better with maven so I think we should look into just how hard it would be to implement. > car file for daytrader module is not generated correctly via c-m-p > --- > > Key: GERONIMO-4221 > URL: https://issues.apache.org/jira/browse/GERONIMO-4221 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.2, 2.1.3, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > > The daytrader tomcat car file isn't generated correctly when building it > using maven c-m-p plugin. It only generates the necessary files for the > org.apache.geronimo.daytrader/daytrader-tomcat/2.0-SNAPSHOT/car module, but > not the files for the two app clients that daytrader has - daytrader-wsclient > & daytrader-streamer-client. After building the plugin using maven, the > target/repository directory looks right to me that contains all 3 modules. > The user impact: after installation of the daytrader tomcat plugin, the > server doesn't recognize the moduleid for either the daytrader-wsclient or > daytrader-streamer-client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Reducing the dojo footprint in Geronimo
Kevan, I am far from having the complete picture, but my understanding for #3: According to a post from Donald previously, this link is very good reference for what process is involved: http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds, in creating our slim 'mydojo.js'. As for the maintenance, i see the scenarios where every app using dojo will now need to cross reference with what is available in mydojo.js to see if the feature they want to use is already included. If not we'll have to re-generate a new slim version of our 'mydojo.js' with the features added. Furthermore, when an app becomes obsolete or is removed, we will need to regenerate a new mydojo.js to remove the unnecessary components. On the user level, I also see some inefficiency where if one wants to deploy a product on AG that uses some dojo subsets which is not in our generated mydojo.js, they'd have to include their own copy of dojo. -Joseph Leong On Wed, Jul 30, 2008 at 10:59 AM, Kevan Miller <[EMAIL PROTECTED]>wrote: > > On Jul 29, 2008, at 3:36 PM, Joseph Leong wrote: > > Hi everyone, > > So i'm building a little widget piece to run on AG and i've come to the > point of deciding whether i'm going to incorporate any (if) dojo/dojox > components into it. I know we've had varying discussions about reducing the > dojo footprint. To summarize i believe the only thing we've agreed on so > far is removing the unncessary /tests , but i'm wondering if the community > had anymore input on keeping dojox around? To summarize it is my > understanding these are the choices suggested so far: > > 1) Removing Dojo from AG and having users include their own optimized Dojo > files for their apps. The downside is that we may be inefficient in > aggregating multiple copies of Dojo. > > 2) Leave Dojo support in AG as is now. We can safely rely on the fact that > their will be no duplicate instances of dojo for those who use it, but we > must now rely on having that dojo overhead even for users who don't utilize > it. > > 3) Creating a slim version of Dojo to support the features relying on it in > AG, thus allowing users who want to demonstrate fundamental dojo features to > utilize it - but however we incur the maintenance overhead of creating new > builds of Dojo to incorporate with AG releases as new fundamental AG > components with Dojo are included. > > Personally, I feel the functionality subset of DojoX captures a lot of what > this Web2.0 era is looking for. Although it may make more sense to go with > option 3, now, i feel it's only a matter of time before we switch over to > option 2. To provide the community with a better grasp of what the DojoX > functionalities are goto: http://dojocampus.org/explorer/#Dojox and you'll > find yourself quite surprised at how innovative and integrated these > technologies are influencing your favorite sites. > > > Thanks a lot for picking this up, again, Joseph. > > Personally, I'd like to see the Dojo footprint within Geronimo reduced. > It's pretty simple to make a full-Dojo plugin that users can install, if > they want a full Dojo library available. IMO, this can meet the needs of > Dojo users (as described in #2). > > Can you help me understand the maintenance overhead of creating a > customized Dojo library? If #3 is high maintenance, I may need to > reconsider. > > --kevan > >
Re: [Help!]G2.1.2 branch build failure saying "org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2" not found in any repository
This is a temporary branch that will be removed once we release 2.1.2. But if you really want to build this branch first execute: mvn install -Dstage=bootstrap and then: mvn install Jarek On Wed, Jul 30, 2008 at 11:40 AM, Forrest <[EMAIL PROTECTED]> wrote: > After checked out 2.1.2 branch, want to build it from scratch, issue > command: > mvn install -e > Then the build error saying > org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2 could > not found, ask me to download and install it manually. Why? > > Maven version tried 2.0.9, 2.0.7, 2.0.5, all same problem. Please help! > thanks! > > Best regards, Forrest
Re: Reducing the dojo footprint in Geronimo
Joseph, I think creating a slim version (like mydojo.js) would be, as I pointed out earlier, useless and also not needed. My proposal was to simply get rid of the dojox components (ie remove the dojox folder). What you suggest is creating one giant preprocessed javascript that has all the dojo, dijit components. For one, this js will be massive and therefore unusable and you would basically subvert the dojo.require process which is similar to import* ing* required components as needed in java. Also, as you said this is a maintenance nightmare. The reason for me to mention the dojo builder which creates a single js was for supporting the webapps which currently use dojox once that is removed from G. For those we could perhaps create a single js with the required components. So here is the updated list of options: 1) Removing Dojo from AG and having users include their own optimized Dojo files for their apps. The downside is that we may be inefficient in aggregating multiple copies of Dojo. 2) Leave Dojo support in AG as is now. We can safely rely on the fact that their will be no duplicate instances of dojo for those who use it, but we must now rely on having that dojo overhead even for users who don't utilize it. 3) Creating a slim version of Dojo essentially by removing the dojox folder and creating custom built js for any components that might still need the dojox functionality. Maintaining these customized scripts might be something that could pose a problem. Finally, we could have a plugin with complete dojo support for applications demanding extra web 2.0 functionality. I would still say that since dojox is considered experimental, developers should be wary of using those features as they are subject to modifications. On Wed, Jul 30, 2008 at 9:39 PM, Joseph Leong <[EMAIL PROTECTED]>wrote: > Kevan, > > I am far from having the complete picture, but my understanding for #3: > According to a post from Donald previously, this link is very good > reference for what process is involved: > http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds, > in creating our slim 'mydojo.js'. > > As for the maintenance, i see the scenarios where every app using dojo will > now need to cross reference with what is available in mydojo.js to see if > the feature they want to use is already included. If not we'll have to > re-generate a new slim version of our 'mydojo.js' with the features added. > Furthermore, when an app becomes obsolete or is removed, we will need to > regenerate a new mydojo.js to remove the unnecessary components. > > On the user level, I also see some inefficiency where if one wants to > deploy a product on AG that uses some dojo subsets which is not in our > generated mydojo.js, they'd have to include their own copy of dojo. > > -Joseph Leong > > > On Wed, Jul 30, 2008 at 10:59 AM, Kevan Miller <[EMAIL PROTECTED]>wrote: > >> >> On Jul 29, 2008, at 3:36 PM, Joseph Leong wrote: >> >> Hi everyone, >> >> So i'm building a little widget piece to run on AG and i've come to the >> point of deciding whether i'm going to incorporate any (if) dojo/dojox >> components into it. I know we've had varying discussions about reducing the >> dojo footprint. To summarize i believe the only thing we've agreed on so >> far is removing the unncessary /tests , but i'm wondering if the community >> had anymore input on keeping dojox around? To summarize it is my >> understanding these are the choices suggested so far: >> >> 1) Removing Dojo from AG and having users include their own optimized Dojo >> files for their apps. The downside is that we may be inefficient in >> aggregating multiple copies of Dojo. >> >> 2) Leave Dojo support in AG as is now. We can safely rely on the fact that >> their will be no duplicate instances of dojo for those who use it, but we >> must now rely on having that dojo overhead even for users who don't utilize >> it. >> >> 3) Creating a slim version of Dojo to support the features relying on it >> in AG, thus allowing users who want to demonstrate fundamental dojo features >> to utilize it - but however we incur the maintenance overhead of creating >> new builds of Dojo to incorporate with AG releases as new fundamental AG >> components with Dojo are included. >> >> Personally, I feel the functionality subset of DojoX captures a lot of >> what this Web2.0 era is looking for. Although it may make more sense to go >> with option 3, now, i feel it's only a matter of time before we switch over >> to option 2. To provide the community with a better grasp of what the DojoX >> functionalities are goto: http://dojocampus.org/explorer/#Dojox and >> you'll find yourself quite surprised at how innovative and integrated these >> technologies are influencing your favorite sites. >> >> >> Thanks a lot for picking this up, again, Joseph. >> >> Personally, I'd like to see the Dojo footprint within Geronimo reduced. >> It's pretty simple to make a full-Dojo plu
Re: Javamail OSGi definitions
I haven't actually tried to send a mail from OSGi yet, but I can try that quite easily (and I will need to try it anyway). I'll try to do that this week and see if I can come up with some problems / requirements. On Wed, Jul 30, 2008 at 5:14 PM, Rick McGuire <[EMAIL PROTECTED]> wrote: > I was looking at the OSGi information that's used for the javamail jars, and > it appears to be currently incomplete, and possibly even incorrect, if I'm > interpreting the information correct. > Javamail is split between a spec component, which is in the Geronimo specs > tree, and a provider component that has its own source tree and build. The > specs component builds a specs jar. The javamail component builds a > provider jar (which has a dependency on the specs jar) and a mail uber-jar > that merges the spec and provider jars into a single jar file. > > Currently, only the javamail specs is building with OSGi information in the > manifest. Here is the manifest from the jar file: > Manifest-Version: 1.0 > Built-By: Rick McGuire > Created-By: Apache Maven Bundle Plugin > Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt > Import-Package: javax.activation,javax.mail;version="1.4",javax.mail.e > vent;version="1.4",javax.mail.internet;version="1.4",javax.mail.searc > h;version="1.4",javax.mail.util;version="1.4" > Bnd-LastModified: 1214586504570 > Export-Package: javax.mail.search;uses:="javax.mail";version="1.4",jav > ax.mail.util;uses:="javax.mail.internet,javax.activation";version="1. > 4",javax.mail.event;uses:="javax.mail";version="1.4",javax.mail.inter > net;uses:="javax.activation,javax.mail,org.apache.geronimo.mail.util" > ;version="1.4",javax.mail;uses:="javax.mail.search,javax.mail.event,j > avax.activation";version="1.4" > Bundle-Version: 1.4.0.SNAPSHOT > Bundle-Name: geronimo-javamail_1.4_spec > Bundle-Description: Javamail 1.4 Specification > Build-Jdk: 1.5.0_11 > Private-Package: org.apache.geronimo.mail.handlers;version="1.4-SNAPSH > OT",org.apache.geronimo.mail.util;version="1.4-SNAPSHOT" > Bundle-DocURL: http://www.apache.org > Bundle-ManifestVersion: 2 > Bundle-Vendor: The Apache Software Foundation > Bundle-SymbolicName: org.apache.geronimo.specs.geronimo-javamail_1.4_s > pec > Implementation-Title: Apache Geronimo > Tool: Bnd-0.0.227 > Implementation-Version: 1.4-SNAPSHOT > > The classes in org.apache.geronimo.mail.handlers and > org.apache.geronimo.mail.util are defined as Private-Package. I'm not sure > this is correct, since the Providers jar file uses those classes. The > merged uber-jar can probably make these private, but I think the provider > requirement would not allow this. Am I correct here? > > Neither the javamail provider jar or mail uber-jar have any OSGi bundle > information. I suspect it needs to be added, since any application that > wishes to use javamail for more than just the javax.mail.* classes (e.g., to > send mail) would need to pull in either the provider bundle or the mail uber > jar bundle. > I'd like to take a stab at fixing this, but I'm not really what the > requirements are for the OSGi enablement. Do we have a documented set of > instructions anywhere? > > Rick > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (GERONIMO-4221) car file for daytrader module is not generated correctly via c-m-p
[ https://issues.apache.org/jira/browse/GERONIMO-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618439#action_12618439 ] David Jencks commented on GERONIMO-4221: In either case there are issues to be solved with the geronimo-plugin.xml. An app client geronimo-plugin.xml should contain info for assembling an app client assembly sufficient to run the app client plugin itself. I think the classifier approach will be more likely to provide a manageable solution to this. I'm thinking of more c-m-p configuration with separate "instance" sections for each app client/classifier. Possibly the element should be moved or duplicated inside > car file for daytrader module is not generated correctly via c-m-p > --- > > Key: GERONIMO-4221 > URL: https://issues.apache.org/jira/browse/GERONIMO-4221 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.2, 2.1.3, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > > The daytrader tomcat car file isn't generated correctly when building it > using maven c-m-p plugin. It only generates the necessary files for the > org.apache.geronimo.daytrader/daytrader-tomcat/2.0-SNAPSHOT/car module, but > not the files for the two app clients that daytrader has - daytrader-wsclient > & daytrader-streamer-client. After building the plugin using maven, the > target/repository directory looks right to me that contains all 3 modules. > The user impact: after installation of the daytrader tomcat plugin, the > server doesn't recognize the moduleid for either the daytrader-wsclient or > daytrader-streamer-client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4218) NullPointerException in ConnectorModuleBuilder
[ https://issues.apache.org/jira/browse/GERONIMO-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-4218: - Assignee: Jarek Gawor > NullPointerException in ConnectorModuleBuilder > -- > > Key: GERONIMO-4218 > URL: https://issues.apache.org/jira/browse/GERONIMO-4218 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1.1 >Reporter: Jürgen Weber >Assignee: Jarek Gawor >Priority: Blocker > > I tried to deploy IMS TM Resource Adapter V10.2.0 runtime (which is > downloadable from > http://www-306.ibm.com/software/data/ims/ims/components/tm-resource-adapter.html#downloads) > in Geronimo 2.1.1. > There is NullPointerException at ConnectorModuleBuilder.java:522 (stacktrace > see below) > The Connector module runs fine with Glassfish 2.1 and JBoss 5. > The geronimo-ra.xml was included in ims1020.rar\META-INF > If there is a problem in geronimo-ra.xml, there should at least be a decent > error message instead of NPE. > geronimo-ra.xml: > http://geronimo.apache.org/xml/ns/j2ee/connector-1.2";> > > > > > com.ibm.connector2.ims.ico.IMSManagedConnectionFactory > > > > > Caused by: java.lang.NullPointerException > at > org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.addConnectorGBeans(ConnectorModuleBuilder.java:522) > at > org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.initContext(ConnectorModuleBuilder.java:499) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4218) NullPointerException in ConnectorModuleBuilder
[ https://issues.apache.org/jira/browse/GERONIMO-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4218: -- Priority: Major (was: Blocker) There is a easy work-around for the NPE so I'm decreasing the priority of the bug. > NullPointerException in ConnectorModuleBuilder > -- > > Key: GERONIMO-4218 > URL: https://issues.apache.org/jira/browse/GERONIMO-4218 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1.1 >Reporter: Jürgen Weber >Assignee: Jarek Gawor > > I tried to deploy IMS TM Resource Adapter V10.2.0 runtime (which is > downloadable from > http://www-306.ibm.com/software/data/ims/ims/components/tm-resource-adapter.html#downloads) > in Geronimo 2.1.1. > There is NullPointerException at ConnectorModuleBuilder.java:522 (stacktrace > see below) > The Connector module runs fine with Glassfish 2.1 and JBoss 5. > The geronimo-ra.xml was included in ims1020.rar\META-INF > If there is a problem in geronimo-ra.xml, there should at least be a decent > error message instead of NPE. > geronimo-ra.xml: > http://geronimo.apache.org/xml/ns/j2ee/connector-1.2";> > > > > > com.ibm.connector2.ims.ico.IMSManagedConnectionFactory > > > > > Caused by: java.lang.NullPointerException > at > org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.addConnectorGBeans(ConnectorModuleBuilder.java:522) > at > org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.initContext(ConnectorModuleBuilder.java:499) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
the create geronimo plugin portlet
Hi, I have a question about this portlet. On this portlet, we gave users the following instruction - The configuration will be saved as a CAR file to your local filesystem. Note: at present, you must manually add a META-INF/geronimo-plugin.xml file to the CAR after you export it in order for it to be a valid plugin. Is that not accurate? I tried to export the daytrader-tomcat car module as a plugin and it seems to generate the geronimo-plugin.xml file ok. If this is incorrect, I'd like to delete the sentence after "Note:". Thx, Lin
Re: the create geronimo plugin portlet
On Jul 30, 2008, at 11:15 AM, Lin Sun wrote: Hi, I have a question about this portlet. On this portlet, we gave users the following instruction - The configuration will be saved as a CAR file to your local filesystem. Note: at present, you must manually add a META-INF/geronimo-plugin.xml file to the CAR after you export it in order for it to be a valid plugin. Is that not accurate? I tried to export the daytrader-tomcat car module as a plugin and it seems to generate the geronimo-plugin.xml file ok. If this is incorrect, I'd like to delete the sentence after "Note:". I think there's some opportunity to edit geronimo-plugin.xml files somewhere in the plugin portlet but I didn't think we actually generated one by default could be wrong. Did you install daytrader-tomcat as an app or using the plugins from the daytrader build? If you installed it as an app evidently we are generating some kind of geronimo-plugin.xml... we should figure out and document exactly what (as well as fixing the wording as you suggest). thanks david jencks Thx, Lin
Re: [Discuss] Moving JAXB classes from GEP to G (was Shifting from xmlbean to JAXB in PlanCreator)
On Jul 29, 2008, at 11:26 AM, Shiva Kumar H R wrote: On Tue, Jul 29, 2008 at 11:45 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: On Jul 29, 2008, at 10:15 AM, Shiva Kumar H R wrote: I too am +1 to moving JAXB classes from Geronimo Eclipse Plug-in (GEP) to Geronimo (G). That way in addition to GEP, G's deployment system in future, Plan Creator and may be some others too will reap the benefits of JAXB. One concern however is about "where should the JAXB classes be moved to?" I see two ways for this (please correct me if I am wrong here): A) Move JAXB code into server (https://svn.apache.org/repos/asf/geronimo/server/trunk/ ) as a new module or plug-in and release it along with server. B) Move JAXB code into specs (https://svn.apache.org/repos/asf/geronimo/specs/trunk/ ) and release it whenever the schema changes. (for ex. I see geronimo-application-2.0.xsd has not changed across G 2.0, 2.1 & 2.2, however G2.0 had plugins-1.2.xsd, while G2.1 & G2.2 have plugins-1.3.xsd). And below is my reasoning to consider Approach-B: i) GEP has traditionally supported previous releases of G too. For. ex. in addition to current G2.1 (and its minor versions), GEP also supports G2.0. A major reason behind this I think is to allow easier porting of applications from one version to another. ii) Now, if we move away JAXB classes from GEP and put it into G server (approach-A), then these JAXB classes will only be available starting from G2.2 onwards and will probably support only latest version of G schemas. So how should GEP support previous versions of G servers and G schemas? iii) If however, we move JAXB classes into G specs and release a new spec-jar everytime a new version of G schema comes up, then GEP will easily be able to support multiple versions of G server & G schemas. Hi Shiva, Can you point us to the JAXB classes that you are referring to? Thanks Kevan for looking into this. Here it is: https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.jee.v21.jaxbmodel/src/main/java/org/apache/geronimo/jee/ geronimo/specs contain our EE specs. I'm having trouble imagining why we would start including non-EE artifacts in specs. Doesn't mean that we can't achieve desired results from a different location. Possible that this work could be associated with migrating to use CDDL licensed deployment descriptor xsd's (and not use comment- removed xsd's generated from tck). --kevan I still haven't really figured out if these are for the jee deployment descriptors or the geronimo plans. I think the ones for the ee dds should be in a single module, possibly in specs or somewhere in server. I think the ones for geronimo plans should be with the builders or in related modules, i.e. one jar per builder. I'm going to look into converting the jetty7 builder (in sandbox) to using jaxb (and actually sxc). thanks david jencks -- Thanks, Shiva
Re: the create geronimo plugin portlet
Hi, >From admin console, we allow users to specify certain info related to plugin metadata, such as author, desp, license, and so on. I deployed daytrader-tomcat as an app, and I checked the geronimo-plugin.xml file was not there in the repository/org/apache/geronimo/daytrader/daytrader-tomcat/2.0-SNAPSHOT/daytrader-tomcat-2.0-SNAPSHOT.car/META-INF directory initially. It got created after I export it as a plugin from the admin console. Thanks, Lin On Wed, Jul 30, 2008 at 2:40 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Jul 30, 2008, at 11:15 AM, Lin Sun wrote: > >> Hi, >> >> I have a question about this portlet. On this portlet, we gave users >> the following instruction - >> >> The configuration will be saved as a CAR file to your local >> filesystem. Note: at present, you must manually add a >> META-INF/geronimo-plugin.xml file to the CAR after you export it in >> order for it to be a valid plugin. >> >> Is that not accurate? I tried to export the daytrader-tomcat car >> module as a plugin and it seems to generate the geronimo-plugin.xml >> file ok. If this is incorrect, I'd like to delete the sentence after >> "Note:". > > I think there's some opportunity to edit geronimo-plugin.xml files somewhere > in the plugin portlet but I didn't think we actually generated one by > default could be wrong. > > Did you install daytrader-tomcat as an app or using the plugins from the > daytrader build? If you installed it as an app evidently we are generating > some kind of geronimo-plugin.xml... we should figure out and document > exactly what (as well as fixing the wording as you suggest). > > thanks > david jencks >> >> >> Thx, Lin > >
Re: [Help!]G2.1.2 branch build failure saying "org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2" not found in any repository
As Jarek states, you need to run bootstrap first. However, I really want to discourage use of this branch. As Jarek states, it is temporary and "frozen" as we are preparing the release. If you want a 2.1.* image you should pull from https://svn.apache.org/repos/asf/geronimo/server/branches/2.1 which is currently 2.1.3-SNAPSHOT (and has just one or two changes since we branched 2.1.2). A Geronimo 2.1.2 release candidate should be available later today if all goes well. Joe Jarek Gawor wrote: This is a temporary branch that will be removed once we release 2.1.2. But if you really want to build this branch first execute: mvn install -Dstage=bootstrap and then: mvn install Jarek On Wed, Jul 30, 2008 at 11:40 AM, Forrest <[EMAIL PROTECTED]> wrote: After checked out 2.1.2 branch, want to build it from scratch, issue command: mvn install -e Then the build error saying org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2 could not found, ask me to download and install it manually. Why? Maven version tried 2.0.9, 2.0.7, 2.0.5, all same problem. Please help! thanks! Best regards, Forrest
[jira] Updated: (GERONIMODEVTOOLS-444) 5 Minute tutorial web browser testcase
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed updated GERONIMODEVTOOLS-444: --- Attachment: GERONIMODEVTOOLS-444.patch Patch gets us closer, it opens the internal web browser inside of Eclipse and points it to the first page of the 5 minute tutorial. However, the HTML objects are not SWT objects so Abbot is unable to find the entry field or button on the page. Still looking for a way to test the actual web site that has been created. > 5 Minute tutorial web browser testcase > -- > > Key: GERONIMODEVTOOLS-444 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-444 > Project: Geronimo-Devtools > Issue Type: Sub-task >Reporter: Tim McConnell >Assignee: B.J. Reed > Attachments: GERONIMODEVTOOLS-444.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4223) NPE when accessing Installed application EAR or Installed web application portlet
NPE when accessing Installed application EAR or Installed web application portlet - Key: GERONIMO-4223 URL: https://issues.apache.org/jira/browse/GERONIMO-4223 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.1 Reporter: Lin Sun Priority: Minor This can be easily recreated using daytrader, which uses a derby datasource and a jms resource. If I delete the daytrader derby datasource and jms resource first via Applications--J2EE connectors, then I am unable to access either the Installed application EAR or Installed web application portlet (got a NPE) caused by the fact that the server is unable to load daytrader's dependency configuration (the daytrader derby datasource and jms resource). We should either present missing dependency exception to the user or warn user when attempting to delete the resources that are needed by other active apps. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 681178
Geronimo Revision: 681178 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080730/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080730
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 39 minutes 11 seconds
[INFO] Finished at: Wed Jul 30 15:51:05 EDT 2008
[INFO] Final Memory: 373M/1014M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080730/logs-1500-tomcat/test.log
Assembly: jetty
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080730/logs-1500-jetty/test.log
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: jetty
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty6-javaee5/2.2-SNAPSHOT/geronimo-jetty6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:42.335
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 31 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:01.549)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:30.068)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:18.584)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:07.002)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:19.233) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:50.959)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:43.373)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:57.750)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:43.323)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:31.856)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.253)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.810)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb
Re: [Help!]G2.1.2 branch build failure saying "org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2" not found in any repository
After manually downloaded and installed car-maven-plugin from http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/buildsupport/car-maven-plugin/2.1.2-SNAPSHOT/car-maven-plugin-2.1.2-20080728.181858-6.jar then just run "mvn install -e" with maven 2.0.9, got build successful of branch 2.1.2. Anyway, thanks for your prompt reply :) Regards, Forrest - Original Message - From: "Joe Bohn" <[EMAIL PROTECTED]> To: Sent: Thursday, July 31, 2008 3:15 AM Subject: Re: [Help!]G2.1.2 branch build failure saying "org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2" not found in any repository As Jarek states, you need to run bootstrap first. However, I really want to discourage use of this branch. As Jarek states, it is temporary and "frozen" as we are preparing the release. If you want a 2.1.* image you should pull from https://svn.apache.org/repos/asf/geronimo/server/branches/2.1 which is currently 2.1.3-SNAPSHOT (and has just one or two changes since we branched 2.1.2). A Geronimo 2.1.2 release candidate should be available later today if all goes well. Joe Jarek Gawor wrote: This is a temporary branch that will be removed once we release 2.1.2. But if you really want to build this branch first execute: mvn install -Dstage=bootstrap and then: mvn install Jarek On Wed, Jul 30, 2008 at 11:40 AM, Forrest <[EMAIL PROTECTED]> wrote: After checked out 2.1.2 branch, want to build it from scratch, issue command: mvn install -e Then the build error saying org.apache.geronimo.buildsupport:car-maven-plugin:maven-plugin:2.1.2 could not found, ask me to download and install it manually. Why? Maven version tried 2.0.9, 2.0.7, 2.0.5, all same problem. Please help! thanks! Best regards, Forrest
[jira] Created: (GERONIMO-4224) Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M
Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M Key: GERONIMO-4224 URL: https://issues.apache.org/jira/browse/GERONIMO-4224 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.1 Environment: HW: Intel x86 Core 2 Duo, 2G Memory SW: Linux Reporter: Xia Ming Priority: Minor Steps: 1. put a large access log in var/catalina/logs 2. start default server instance at port 8080 3. login admin console 4. filter access log including the timeframe the large access log spans Problem: Outofmemory exception thowed in the viewwebaccesslog portlet window. Instead of outofmemory exception throwed, suggest to either improve web access logging to split by size, or give a more friendly msg when log file size is too large. I would prefer the former one, because it will improve maintainability of geronimo in a long run environment. **exception msg** Error rendering portlet. javax.portlet.PortletException at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:191) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) 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:233) 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:406) 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:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.connect
Re: Fixing usability/accessibility issues in Admin Console
On Jul 30, 2008, at 2:50 AM, Jack wrote: Before this post sinks, would someone help to put the accessibility guidelines somewhere in our doc? Maybe in the coding standard? If I can get the write access (I've signed ICLA), I can do that if no one objects... I doubt there will be any objections. Could a Confluence geronimo- admin or confluence-admin (not sure which you need to be) give Jack access to the wiki? --kevan
Re: Documentation of new 2.2 features in current wiki?
On Jul 29, 2008, at 6:25 PM, David Jencks wrote: On Jul 29, 2008, at 2:06 PM, Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with 2.1 content. OK, but who exactly is going to do all this wiki maintenance that you are proposing? I suggest mixing the docs because I don't think it will be confusing with prominent enough labels and I don't think that wiki maintenance is going to happen, no matter how many good intentions people now have. Furthermore I would much rather that anyone with the knowledge to organize the documentation and interest in working on it spend it on content rather than continual reorganization. I agree with Jarek. I'd prefer that we keep 2.1 and 2.2 content separated. We've still got G 1.1 users. I don't see how a documentation super-set is going to be viable, in the long term. At some point, the documentation would need to be separated. Better, I think, to start out that way and keep things cleaner for 2.1 users. --kevan
[VOTE] Geronimo Server 2.1.2 Release
All, I've prepared a release candidate of Geronimo Server 2.1.2 for your review and vote. The source for the Geronimo Server 2.1.2 release currently resides here: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.2 When the release vote is approved, I will svn mv the code to https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.2 An archive of this source code can be found here: http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.tar.gz OR http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/ contains the 10 Java EE, Minimal, and Framework server binary distributions to be released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES, README, NOTICE, LICENSE, DISCLAIMER, and source code archives for the release. These extra txt files were included so that they could be leveraged by GEP if necessary (they are also included in the assembly images). For your convenience, here are pointers to the urls for the distributions in zip format: http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6-javaee5-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6-minimal-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-tomcat6-javaee5-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-tomcat6-minimal-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-framework-2.1.2-bin.zip The maven artifacts for the release can be found here: http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.2/ When the release vote is approved, these maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release Geronimo 2.1.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.1.2 (please provide rationale) 72 hours would expire at 11:00PM ET on Saturday evening, 8/2. However, the vote may go longer while the tck results are verified. Joe Bohn
[DISCUSS] Geronimo Server 2.1.2 Release
Discussion thread for the Geronimo Server 2.1.2 release vote.
m2eclipse
Has anybody had any success using the m2eclipse plugin with Geronimo? I gave it a try, but it's running out of memory (despite my giving it as much heap memory as Eclipse/JVM would let me). --kevan
[jira] Resolved: (GERONIMO-4218) NullPointerException in ConnectorModuleBuilder
[ https://issues.apache.org/jira/browse/GERONIMO-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4218. --- Resolution: Fixed Fix Version/s: 2.2 2.1.3 Committed changes to trunk (revision 681268) and branches/2.1 (revision 681269) to handle geronimo-ra.xml without resourceadapter-instance element. If the Geronimo plan does not have the resourceadapter-instance element, a gbean for the resourceadapter-instance will be created using the defaults (e.g. the default work manager). > NullPointerException in ConnectorModuleBuilder > -- > > Key: GERONIMO-4218 > URL: https://issues.apache.org/jira/browse/GERONIMO-4218 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1.1 >Reporter: Jürgen Weber >Assignee: Jarek Gawor > Fix For: 2.1.3, 2.2 > > > I tried to deploy IMS TM Resource Adapter V10.2.0 runtime (which is > downloadable from > http://www-306.ibm.com/software/data/ims/ims/components/tm-resource-adapter.html#downloads) > in Geronimo 2.1.1. > There is NullPointerException at ConnectorModuleBuilder.java:522 (stacktrace > see below) > The Connector module runs fine with Glassfish 2.1 and JBoss 5. > The geronimo-ra.xml was included in ims1020.rar\META-INF > If there is a problem in geronimo-ra.xml, there should at least be a decent > error message instead of NPE. > geronimo-ra.xml: > http://geronimo.apache.org/xml/ns/j2ee/connector-1.2";> > > > > > com.ibm.connector2.ims.ico.IMSManagedConnectionFactory > > > > > Caused by: java.lang.NullPointerException > at > org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.addConnectorGBeans(ConnectorModuleBuilder.java:522) > at > org.apache.geronimo.connector.deployment.ConnectorModuleBuilder.initContext(ConnectorModuleBuilder.java:499) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4224) Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M
[ https://issues.apache.org/jira/browse/GERONIMO-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618602#action_12618602 ] Jarek Gawor commented on GERONIMO-4224: --- It seems to me like the problem is in JettyLogManager/TomcatLogManager where it effectively attempts to read-in the entire log file into memory - that's even before parsing it. > Outofmemory exception throwed by WebAccessLogViewer if the access log file > size is too large, such as more than 200M > > > Key: GERONIMO-4224 > URL: https://issues.apache.org/jira/browse/GERONIMO-4224 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: HW: Intel x86 Core 2 Duo, 2G Memory > SW: Linux >Reporter: Xia Ming >Priority: Minor > > Steps: > 1. put a large access log in var/catalina/logs > 2. start default server instance at port 8080 > 3. login admin console > 4. filter access log including the timeframe the large access log spans > Problem: > Outofmemory exception thowed in the viewwebaccesslog portlet window. Instead > of outofmemory exception throwed, suggest to either improve web access > logging to split by size, or give a more friendly msg when log file size is > too large. I would prefer the former one, because it will improve > maintainability of geronimo in a long run environment. > **exception msg** > Error rendering portlet. > javax.portlet.PortletException > at > org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:191) > at > org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) > at > org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) > at > org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) > at > jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) > at > org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) > at > jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) > at > jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) > at > org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) > at > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) > at > org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) > 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:233) > 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(Geroni
Re: m2eclipse
I ran into similar problems and stopped using it. ++Vamsi On Thu, Jul 31, 2008 at 8:48 AM, Kevan Miller <[EMAIL PROTECTED]>wrote: > Has anybody had any success using the m2eclipse plugin with Geronimo? I > gave it a try, but it's running out of memory (despite my giving it as much > heap memory as Eclipse/JVM would let me). > > --kevan >
