Re: Whence the geronimo kernel?
This is defintely a good move! How will that affect the programming model around Geronimo? Obviously some users are not happy with the complexity of the deployment plan [1]. -Jack [1] http://www.nabble.com/your-current-Geronimo-evaluation-td22329850s134.html 2009/3/5 Ivan > It is a good idea. > I encounter some similar issues about the multiparent classloader. From the > pom.xml, currently, it is hard to know which jar is in the classpath. The > dependies between the configurations are also too complex, I notice that the > restart/reload codes in the configurationManager is very very ... > Maybe we could replace all the codes in the configurationManager, and just > delegate it to the OSGI module/lifecycle layer. > Thanks ! > > > 2009/3/5 David Jencks > > Geronimo has been around for a while and despite the many good features >> gbeans and the geronimo kernel are not catching on big time. I think we >> want to consider taking action now to avoid ending up being dragged down by >> supporting a dead container. Here are a few thoughts. >> >> Actual problems with geronimo: >> - gbeans are too restrictive. It's too hard to instantiate other peoples >> components as gbeans. GBeans don't support common patterns like factory >> methods, factory beans, etc etc, and require the component to be >> instantiated directly by the gbean framework. >> - it's too hard to get the classloaders to work. The most common problem >> is a class cast exception due to loading the same jar in two plugins. >> NoClassDefFound errors from an optional jar in a child classloader are also >> really annoying. >> >> Really good things about geronimo I haven't seen elsewhere (at least in >> one place): >> - gbean dependencies work across plugins. Dependencies are a unified >> system, not per-plugin. >> - gbean dependencies are resolved in the ancestors of a plugin, not server >> wide. This means that you can't make a partially specified dependency >> ambiguous by deploying additional plugins. I consider this an extremely >> important feature for predictability. >> - plugin dependencies allow assembly of a server from the explicit >> dependencies which are normally the same as the maven dependencies. >> >> Other projects and specs that have stuff we should look into: >> maven. Maven has a lot better infrastructure for dealing with dependency >> resolution from partial transitive dependency specification than we do. We >> should look into using more of their infrastructure. >> osgi. osgi has a lot of similarities to geronimo. The osgi classloading >> model is getting a lot of people excited. The import-bundle idea is pretty >> much the same as our classloader model where every jar is a plugin. I don't >> know if people are really using the allegedly recommended method of >> specifying imports and exports and letting the osgi runtime figure out where >> they come from; this seems worth investigating to me. Also, we get periodic >> inquiries about when we are going to support osgi and the was ce folks get >> even more. >> osgi blueprint service (rfc 124) This appears to be a simple wiring >> framework for a single plugin. IIUC it uses the osgi service registry for >> component dependencies between bundles. >> xbean-spring. I'd be reluctant to try to implement a blueprint service >> that didn't provide the xbean-spring capabilities really well >> ee6 dependency injection. EE6 is going to have a pretty sophisticated >> dependency injection service which we'll need to support anyway. We should >> try to figure out how much of the core we can assemble using it. >> >> Other great stuff we have: >> xbean-reflect, xbean-finder, xbean-spring >> >> >> These ideas have been floating around in my head for a long time and I've >> chatted with various people about them occasionally. While more discussion >> is certainly needed on everything here I need to do some implementation to >> understand much more. So, what I'm planning to do: >> >> Dave's crazy work plan... >> - Try to use the osgi classloader. I think this involves putting the >> classloader creation in Configuration into a service. Configurations will >> turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so >> the Configuration bundle activator should be able to use it to resolve >> cross-plugin dependencies. >> - try to figure out how maven dependency resolution fits into osgi. >> - see if eclipse p2 is relevant for provisioning geronimo repositories >> >> at this point I think geronimo would be running on osgi, still using >> gbeans. >> >> - look into relaxing the gbean framework so it is more plugin-at-a-time >> rather than gbean-at-a-time >> - see how that differs from the blueprint service, ee DI, and >> xbean-spring. Try to support all of these at once. >> >> Thoughts? Counter proposals? Anyone interested? >> >> many thanks >> david jencks >> >> > > > -- > Ivan >
[jira] Commented: (GERONIMO-4544) Error occured when repeatedly create DB or records
[ https://issues.apache.org/jira/browse/GERONIMO-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679107#action_12679107 ] Ivan commented on GERONIMO-4544: Thanks for your help, Jarek and David ! > Error occured when repeatedly create DB or records > -- > > Key: GERONIMO-4544 > URL: https://issues.apache.org/jira/browse/GERONIMO-4544 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.4 > Environment: JAVA5 + RHEL 5.3 (X86) + Firefox 3.0.5 >Reporter: lily seattle >Assignee: Jarek Gawor > Fix For: 2.1.4, 2.2 > > Attachments: Geronimo-4544-for2.1.patch, Geronimo-4544-forTrunk.patch > > > steps: > 1. login console > 2. Click Embedded DB -> DB Manager. > 3. Filling the Create DB blank with TestDB, click Create. > 4.Create a table using: > CREATE TABLE CUSTOMER ( > ID INTEGER NOT NULL PRIMARY KEY, > NAMEVARCHAR(45), > BIRTHDATE DATE, > SSS_NO VARCHAR(25), > ADDRESS VARCHAR(60), > ANNUAL_SALARY DOUBLE, > LOAN_AMOUNT DOUBLE > ); > 5. Insert a record: > INSERT INTO CUSTOMER VALUES > (001,'hi','02/19/2009','111','somewhere',100,150); > Now, if create the same table again, or Insert the same record, errors will > occur. Also the Table can't be accessed > any more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
It is a good idea. I encounter some similar issues about the multiparent classloader. From the pom.xml, currently, it is hard to know which jar is in the classpath. The dependies between the configurations are also too complex, I notice that the restart/reload codes in the configurationManager is very very ... Maybe we could replace all the codes in the configurationManager, and just delegate it to the OSGI module/lifecycle layer. Thanks ! 2009/3/5 David Jencks > Geronimo has been around for a while and despite the many good features > gbeans and the geronimo kernel are not catching on big time. I think we > want to consider taking action now to avoid ending up being dragged down by > supporting a dead container. Here are a few thoughts. > > Actual problems with geronimo: > - gbeans are too restrictive. It's too hard to instantiate other peoples > components as gbeans. GBeans don't support common patterns like factory > methods, factory beans, etc etc, and require the component to be > instantiated directly by the gbean framework. > - it's too hard to get the classloaders to work. The most common problem > is a class cast exception due to loading the same jar in two plugins. > NoClassDefFound errors from an optional jar in a child classloader are also > really annoying. > > Really good things about geronimo I haven't seen elsewhere (at least in one > place): > - gbean dependencies work across plugins. Dependencies are a unified > system, not per-plugin. > - gbean dependencies are resolved in the ancestors of a plugin, not server > wide. This means that you can't make a partially specified dependency > ambiguous by deploying additional plugins. I consider this an extremely > important feature for predictability. > - plugin dependencies allow assembly of a server from the explicit > dependencies which are normally the same as the maven dependencies. > > Other projects and specs that have stuff we should look into: > maven. Maven has a lot better infrastructure for dealing with dependency > resolution from partial transitive dependency specification than we do. We > should look into using more of their infrastructure. > osgi. osgi has a lot of similarities to geronimo. The osgi classloading > model is getting a lot of people excited. The import-bundle idea is pretty > much the same as our classloader model where every jar is a plugin. I don't > know if people are really using the allegedly recommended method of > specifying imports and exports and letting the osgi runtime figure out where > they come from; this seems worth investigating to me. Also, we get periodic > inquiries about when we are going to support osgi and the was ce folks get > even more. > osgi blueprint service (rfc 124) This appears to be a simple wiring > framework for a single plugin. IIUC it uses the osgi service registry for > component dependencies between bundles. > xbean-spring. I'd be reluctant to try to implement a blueprint service > that didn't provide the xbean-spring capabilities really well > ee6 dependency injection. EE6 is going to have a pretty sophisticated > dependency injection service which we'll need to support anyway. We should > try to figure out how much of the core we can assemble using it. > > Other great stuff we have: > xbean-reflect, xbean-finder, xbean-spring > > > These ideas have been floating around in my head for a long time and I've > chatted with various people about them occasionally. While more discussion > is certainly needed on everything here I need to do some implementation to > understand much more. So, what I'm planning to do: > > Dave's crazy work plan... > - Try to use the osgi classloader. I think this involves putting the > classloader creation in Configuration into a service. Configurations will > turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so > the Configuration bundle activator should be able to use it to resolve > cross-plugin dependencies. > - try to figure out how maven dependency resolution fits into osgi. > - see if eclipse p2 is relevant for provisioning geronimo repositories > > at this point I think geronimo would be running on osgi, still using > gbeans. > > - look into relaxing the gbean framework so it is more plugin-at-a-time > rather than gbean-at-a-time > - see how that differs from the blueprint service, ee DI, and xbean-spring. > Try to support all of these at once. > > Thoughts? Counter proposals? Anyone interested? > > many thanks > david jencks > > -- Ivan
[jira] Commented: (GERONIMO-4555) Can't start App Client after stop it from console
[ https://issues.apache.org/jira/browse/GERONIMO-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679098#action_12679098 ] Ivan commented on GERONIMO-4555: In the current app client portlet, when it detects that if the type of the configuration is CAR, then it thought that it is a client application, so do not list any action (such as start/restart). The clause is correct if the module is of client side, for server side, it seems that we still allow to start/stop/restart it. So I add an extra clause to check it. Thanks ! > Can't start App Client after stop it from console > -- > > Key: GERONIMO-4555 > URL: https://issues.apache.org/jira/browse/GERONIMO-4555 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.4 > Environment: OS:Windows 2003 JDK:1.5 >Reporter: viola.lu >Priority: Minor > Attachments: Geronimo-4555.patch > > > 1.Deploy an application client, and stop its server module, but after that > there is just an "uninstall"button left, can't re-start it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4571) App client still can run after stop app client server env module
[ https://issues.apache.org/jira/browse/GERONIMO-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679083#action_12679083 ] David Jencks commented on GERONIMO-4571: This is not really a problem. The server side app client module is only there to fulfil some silly jsr77 requirements. It doesn't actually do anything useful. > App client still can run after stop app client server env module > > > Key: GERONIMO-4571 > URL: https://issues.apache.org/jira/browse/GERONIMO-4571 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: application client >Affects Versions: 2.1.4 > Environment: OS:win2003, JDK 1.5 >Reporter: viola.lu >Priority: Minor > Attachments: test1.jar > > > Steps: > 1.Deploy the attached app client to g server, client env module is > sample/appclient/1.0/car, server env module is sample/appserver/1.0/car. > and sample/appserver/1.0/car status is running > 2.I stopped sample/appserver/1.0/car, run command :client.bat/client.sh > sample/appclient/1.0/car, it still can work, and print out string. > So any one familiar with standalone app client running behavior give some > hints?Whether app client server module status is stopped or running, app > client still can run?Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4555) Can't start App Client after stop it from console
[ https://issues.apache.org/jira/browse/GERONIMO-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679082#action_12679082 ] David Jencks commented on GERONIMO-4555: I'm not sure I understand the proposed fix for the problem. However the server side client module is a very silly thing that does nothing useful but is pretty much required for jsr77 compliance. Basically it says the ear has an app client distributed inside... but has no influence on anything's behavior. > Can't start App Client after stop it from console > -- > > Key: GERONIMO-4555 > URL: https://issues.apache.org/jira/browse/GERONIMO-4555 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.4 > Environment: OS:Windows 2003 JDK:1.5 >Reporter: viola.lu >Priority: Minor > Attachments: Geronimo-4555.patch > > > 1.Deploy an application client, and stop its server module, but after that > there is just an "uninstall"button left, can't re-start it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter
[ https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679081#action_12679081 ] David Jencks commented on GERONIMO-4549: Jack, I don't completely understand the xbean jndi code however I think the reason for some of the things like removeNotEmptyContext are to support federated jndi contexts. So I recommend you try to understand federated jndi contexts better than I do before changing the code... or come up with more unit tests. > JMS resource jndi entries are not removed after uninstalling the JMS connect > adapter > > > Key: GERONIMO-4549 > URL: https://issues.apache.org/jira/browse/GERONIMO-4549 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.1.4 >Reporter: Forrest Xia >Priority: Blocker > Fix For: 2.1.4, 2.2 > > > Steps to reproduce this problem: > 1. login admin console > 2. Create a ActiveMQ resource connector with the wizard > 3. Deploy it and check it is in running state > 4. Click J2EE connector to uninstall it > 5. Check JNDI viewer, you will see the JNDI entry still there, even you've > uninstalled it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4571) App client still can run after stop app client server env module
[ https://issues.apache.org/jira/browse/GERONIMO-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMO-4571: --- Attachment: test1.jar > App client still can run after stop app client server env module > > > Key: GERONIMO-4571 > URL: https://issues.apache.org/jira/browse/GERONIMO-4571 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: application client >Affects Versions: 2.1.4 > Environment: OS:win2003, JDK 1.5 >Reporter: viola.lu >Priority: Minor > Attachments: test1.jar > > > Steps: > 1.Deploy the attached app client to g server, client env module is > sample/appclient/1.0/car, server env module is sample/appserver/1.0/car. > and sample/appserver/1.0/car status is running > 2.I stopped sample/appserver/1.0/car, run command :client.bat/client.sh > sample/appclient/1.0/car, it still can work, and print out string. > So any one familiar with standalone app client running behavior give some > hints?Whether app client server module status is stopped or running, app > client still can run?Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4571) App client still can run after stop app client server env module
App client still can run after stop app client server env module Key: GERONIMO-4571 URL: https://issues.apache.org/jira/browse/GERONIMO-4571 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: application client Affects Versions: 2.1.4 Environment: OS:win2003, JDK 1.5 Reporter: viola.lu Priority: Minor Steps: 1.Deploy the attached app client to g server, client env module is sample/appclient/1.0/car, server env module is sample/appserver/1.0/car. and sample/appserver/1.0/car status is running 2.I stopped sample/appserver/1.0/car, run command :client.bat/client.sh sample/appclient/1.0/car, it still can work, and print out string. So any one familiar with standalone app client running behavior give some hints?Whether app client server module status is stopped or running, app client still can run?Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4544) Error occured when repeatedly create DB or records
[ https://issues.apache.org/jira/browse/GERONIMO-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679079#action_12679079 ] David Jencks commented on GERONIMO-4544: While resetting autocommit won't hurt anything its not necessary either. When the connection gets put back in the pool a cleanup method is called to make sure its in a known state and in particular it resets autocommit. If you aren't using the tranql wrappers but some other jdbc-jca wrapper this might not have been implemented correctly but with tranql I'm pretty sure it's working well. > Error occured when repeatedly create DB or records > -- > > Key: GERONIMO-4544 > URL: https://issues.apache.org/jira/browse/GERONIMO-4544 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.4 > Environment: JAVA5 + RHEL 5.3 (X86) + Firefox 3.0.5 >Reporter: lily seattle >Assignee: Jarek Gawor > Fix For: 2.1.4, 2.2 > > Attachments: Geronimo-4544-for2.1.patch, Geronimo-4544-forTrunk.patch > > > steps: > 1. login console > 2. Click Embedded DB -> DB Manager. > 3. Filling the Create DB blank with TestDB, click Create. > 4.Create a table using: > CREATE TABLE CUSTOMER ( > ID INTEGER NOT NULL PRIMARY KEY, > NAMEVARCHAR(45), > BIRTHDATE DATE, > SSS_NO VARCHAR(25), > ADDRESS VARCHAR(60), > ANNUAL_SALARY DOUBLE, > LOAN_AMOUNT DOUBLE > ); > 5. Insert a record: > INSERT INTO CUSTOMER VALUES > (001,'hi','02/19/2009','111','somewhere',100,150); > Now, if create the same table again, or Insert the same record, errors will > occur. Also the Table can't be accessed > any more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4570) deploy error after using login to save the name and password
[ https://issues.apache.org/jira/browse/GERONIMO-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-4570: - Assignee: Jarek Gawor > deploy error after using login to save the name and password > > > Key: GERONIMO-4570 > URL: https://issues.apache.org/jira/browse/GERONIMO-4570 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.1.4 > Environment: AIX(32 bit)+JAVA5 >Reporter: running Wang >Assignee: Jarek Gawor > > 1. start geronimo server > 2. remove file $HOME/.geronimo-deployer > 3. run gsh to enter gshell mode > 4. run deploy/login -u username -w password to save the username and password > 5. run deploy/connect > 6. run deploy/list-modules > output: ERROR IllegalStateException:Disconnected > if run deploy/list-plugins, output will be ERROR NullPointException:null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4555) Can't start App Client after stop it from console
[ https://issues.apache.org/jira/browse/GERONIMO-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4555: --- Attachment: Geronimo-4555.patch Only checking whether the type is CAR is not enough to know it is a clientside or serverside application client. Add an extra clause, whether the configuration holds any owned configuration. It seems that the server side client should always have the client side as the owned configuration. By the way, I wonder what is the server side client's role? From the codes, I found when the application client is standalone, a server client is always created. But I did not see any interaction between them in the codes. Could anyone shed light on it ? Thanks! > Can't start App Client after stop it from console > -- > > Key: GERONIMO-4555 > URL: https://issues.apache.org/jira/browse/GERONIMO-4555 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.4 > Environment: OS:Windows 2003 JDK:1.5 >Reporter: viola.lu >Priority: Minor > Attachments: Geronimo-4555.patch > > > 1.Deploy an application client, and stop its server module, but after that > there is just an "uninstall"button left, can't re-start it. -- 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: 750267
Geronimo Revision: 750267 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/build-2100.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 36 minutes [INFO] Finished at: Wed Mar 04 21:39:51 EST 2009 [INFO] Final Memory: 668M/996M [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/20090304/logs-2100-tomcat/test.log [INFO] snapshot org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking for updates from codehaus-snapshots [INFO] Using assembly artifact: org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided [INFO] Using geronimoHome: /home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT [INFO] Installing assembly... [INFO] Expanding: /home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-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:40.875 [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 36 test builds [INFO] [INFO] --- [INFO] [INFO] commands-testsuite/deploy RUNNING [INFO] commands-testsuite/deploy SUCCESS (0:00:59.541) [INFO] commands-testsuite/gshell RUNNING [INFO] commands-testsuite/gshell SUCCESS (0:00:27.709) [INFO] commands-testsuite/jaxws RUNNING [INFO] commands-testsuite/jaxws SUCCESS (0:00:33.477) [INFO] commands-testsuite/shutdownRUNNING [INFO] commands-testsuite/shutdownSUCCESS (0:00:15.915) [INFO] concurrent-testsuite/concurrent-basic RUNNING [INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:24.025) [INFO] console-testsuite/advanced RUNNING [INFO] console-testsuite/advanced SUCCESS (0:01:19.848) [INFO] console-testsuite/basicRUNNING [INFO] console-testsuite/basicSUCCESS (0:01:43.340) [INFO] corba-testsuite/corba-helloworld RUNNING [INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:49.256) [INFO] corba-testsuite/corba-marshal RUNNING [INFO] corba-testsuite/corba-marshal SUCCESS (0:01:18.856) [INFO] corba-testsuite/corba-mytime RUNNING [INFO] corba-testsuite/corba-mytime SUCCESS (0:00:41.707) [INFO] deployment-testsuite/deployment-tests RUNNING [INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:30.186) [INFO] deployment-testsuite/jca-cms-tests RUNNING [INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:32.861) [INFO] deployment-testsuite/manifestcp-tests RUNNING [INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:33.616) [INFO] enterprise-testsuite/ejb-tests RUNNING [INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:56.499) [INFO] enterprise-testsuite/jms-tests RUNNING [INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:54.619) [INFO] enterprise-testsuite/jpa-tests RUNNING [INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:03.852) [INFO] enterprise-testsuite/sec-clientRUNNING [INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.970) [INFO] enterprise-testsuite/sec-tests RUNNING [INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.445) [INFO] security-testsuite/test-security RUNNING [INFO] security-testsuite/test-security FAILURE (0:00:38.136) Java returned: 1 [INFO] web-testsuite/test-2.1-jspsRUNNING [INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.025) [INFO] web-testsuite/test-2.5-servletsRUNNING [INFO] web-testsuite/test-2.5-servlets
[jira] Updated: (GERONIMO-4567) Gshell deploy/assemble command on a remote server cannot work
[ https://issues.apache.org/jira/browse/GERONIMO-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] caiwenjing updated GERONIMO-4567: - Component/s: commands Fix Version/s: 2.1.4 > Gshell deploy/assemble command on a remote server cannot work > - > > Key: GERONIMO-4567 > URL: https://issues.apache.org/jira/browse/GERONIMO-4567 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: commands >Affects Versions: 2.1.4 > Environment: remote : JAVA5 + SOLARIS 10 SPARC (32BIT) > local : Windows xp professional sp3 >Reporter: caiwenjing > Fix For: 2.1.4 > > > 1.Change the RemoteDeployHostname to the remote machine's IP in file > var/config/config-substitutions.properties in the remote machine. > 2.Add the remote machine's IP to /etc/hosts in the remote machine. > 2.Start the server on the remote machine. > 3.Cd into /bin directory on the local machine, launch gsh and run: > deploy/connect -s REMOTE_IP -p PORT > 4.run: deploy/assemble, input a server artifact name > Then console shows: > ERROR UnmarshalException: error unmarshalling return; nested exception is: > java.lang.ClassNotFoundException: > com.sun.org.apache.xerces.internal.dom.ElementNSImpl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4570) deploy error after using login to save the name and password
deploy error after using login to save the name and password Key: GERONIMO-4570 URL: https://issues.apache.org/jira/browse/GERONIMO-4570 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.4 Environment: AIX(32 bit)+JAVA5 Reporter: running Wang 1. start geronimo server 2. remove file $HOME/.geronimo-deployer 3. run gsh to enter gshell mode 4. run deploy/login -u username -w password to save the username and password 5. run deploy/connect 6. run deploy/list-modules output: ERROR IllegalStateException:Disconnected if run deploy/list-plugins, output will be ERROR NullPointException:null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4569) Built sample plugin by using new tomcat6-deployer cannot be installed on server
[ https://issues.apache.org/jira/browse/GERONIMO-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679035#action_12679035 ] Forrest Xia commented on GERONIMO-4569: --- ok, got it. > Built sample plugin by using new tomcat6-deployer cannot be installed on > server > --- > > Key: GERONIMO-4569 > URL: https://issues.apache.org/jira/browse/GERONIMO-4569 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 2.1.4 >Reporter: Forrest Xia >Assignee: David Jencks >Priority: Critical > > Recently, when I am building some 2.1 branch samples plugins, I found that > built sample plugins are all not installable. > A message on admin console like this: > "A problem has occured: > org.apache.geronimo.kernel.config.LifecycleException: start of > org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed" > An exception in stdout/stderr like this: > "Caused by: > org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve > reference "Container" in gbean > org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT > to a gbean matching the pattern [?name=WebContainer#] > at > org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)" > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Whence the geronimo kernel?
Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import- bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration bundle activator should be able to use it to resolve cross-plugin dependencies. - try to figure out how maven dependency resolution fits into osgi. - see if eclipse p2 is relevant for provisioning geronimo repositories at this point I think geronimo would be running on osgi, still using gbeans. - look into relaxing the gbean framework so it is more plugin-at-a- time rather than gbean-at-a-time - see how that differs from the blueprint service, ee DI, and xbean- spring. Try to support all of these at once. Thoughts? Counter proposals? Anyone interested? many thanks david jencks
[jira] Commented: (GERONIMO-4297) Include TranQL connector for Oracle RAC
[ https://issues.apache.org/jira/browse/GERONIMO-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679003#action_12679003 ] David Jencks commented on GERONIMO-4297: tranql oracle wraper v 1.4 released. > Include TranQL connector for Oracle RAC > --- > > Key: GERONIMO-4297 > URL: https://issues.apache.org/jira/browse/GERONIMO-4297 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: connector >Affects Versions: 2.0.2, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 >Reporter: Donald Woods >Assignee: David Jencks >Priority: Minor > Fix For: 2.1.4, 2.2 > > > Can be accomplished once patch is provided in TRANQL-10 and a new connector > released by TranQL team. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4523) Security Realm based Group-Role Mapping
[ https://issues.apache.org/jira/browse/GERONIMO-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4523. -- Resolution: Fixed Fix Version/s: 2.2 I don't think anything more on this will get done. > Security Realm based Group-Role Mapping > --- > > Key: GERONIMO-4523 > URL: https://issues.apache.org/jira/browse/GERONIMO-4523 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: security >Reporter: Jürgen Weber >Assignee: David Jencks > Fix For: 2.2 > > > For secured applications you currently need a Geronimo-specific deployment > plan which defines among others a mapping of realm groups onto JEE roles. > This goes against the spirit of EJB3 which replaces deployment descriptors > with annotations. > It would be desirable to be able to run a standard-conforming JEE application > under container security without the need for Geronimo-specific deployment > plans. > But this raises the need of another mean to specify Group-Role Mapping. I > suggest that this can be specified at the security-realm level. A realm > should be linked to a mapping (n:1 mapping, several realms should potentially > use the same mapping). There should be a default identity mapping, if you > have several thousands of users in LDAP. > Mappings should be definable via console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4554. --- Resolution: Fixed Committed a set of changes that do not rely on config substitution properties to discover the web container to trunk (revision 750189) and branches/2.1 (revision 750233). > Cant deploy an ejb web service as a plugin using car-maven-plugin > - > > Key: GERONIMO-4554 > URL: https://issues.apache.org/jira/browse/GERONIMO-4554 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.3 >Reporter: David Jencks >Assignee: Jarek Gawor > Fix For: 2.1.4, 2.2 > > > I tried to deploy an ejb web service using the car-maven-plugin. The cxf and > axis2 ejb deployers set up the wslink gbean with a reference to the web > container. This is set in the plan for the deployers as "WebContainer" but > the geronimo-plugin.xml overrides this to "${webContainer}". The jetty and > tomcat plugins use a config-substitutions entry to e.g. set > webContainer=JettyWebContainer > So, this all works on a server where all the plugins are installed. However > it doesn't work when using the car-maven-plugin since the config.xml > overrides and config-substitutions are not applied. > We need to either make the config modifications work for the car-maven-plugin > or make sure none of the deployers the car-maven-plugin might use depend on > these customizations to work. For instance, we could change all the names to > WebContainer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
private repo files and apache headers
Should we include apache license headers in the poms and README that we provide for the private builds in our repository? Joe
Re: svn commit: r700193 - in /geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main: java/org/apache/geronimo/console/internaldb/ resources/ webapp/WEB-INF/view/internaldb/
On Mar 4, 2009, at 12:52 PM, Joe Bohn wrote: I know this is going way back in time ... but any idea why this change deleted the content of dbViewerMaximized.jsp but kept the empty file around? That's easy to do when you run patch -p0 which can empty files but not run svn rm on them. I discovered this when checking for source headers. This file is flagged because it doesn't contain a header - but more than that it doesn't contain anything at all. I presume we can delete the entire file. Does anybody know of any reason why we should not do this? There are a few other instances of similar files that we need to deal with as well. I expect the *Maximized.jsp were never referenced and the patch author deleted them but did not succeed in conveying the need to run svn rm to the patch applier. thanks david jencks Joe dwo...@apache.org wrote: Author: dwoods Date: Mon Sep 29 11:09:17 2008 New Revision: 700193 URL: http://svn.apache.org/viewvc?rev=700193&view=rev Log: GERONIMO-4225 Allow Run SQL portlet run sql against any configured data source. Thanks to Michal Borowiecki for the patch. Added: geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/webapp/WEB-INF/view/internaldb/ listDatabasesMaximized.jsp (with props) geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/webapp/WEB-INF/view/internaldb/ listTablesMaximized.jsp (with props) geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/webapp/WEB-INF/view/internaldb/ viewTableContentsMaximized.jsp (with props) Modified: geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/java/org/apache/geronimo/console/internaldb/ DBViewerHelper.java geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/java/org/apache/geronimo/console/internaldb/ DBViewerPortlet.java geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/java/org/apache/geronimo/console/internaldb/ DerbyConnectionUtil.java geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/java/org/apache/geronimo/console/internaldb/ RunSQLHelper.java geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/java/org/apache/geronimo/console/internaldb/ RunSQLPortlet.java geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/resources/systemdatabase.properties geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/webapp/WEB-INF/view/internaldb/ dbViewerMaximized.jsp geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/webapp/WEB-INF/view/internaldb/runSQLNormal.jsp Modified: geronimo/server/branches/2.1/plugins/system-database/ sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/ DBViewerHelper.java URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java?rev=700193&r1=700192&r2=700193&view=diff = = = = = = = = = = --- geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/java/org/apache/geronimo/console/internaldb/ DBViewerHelper.java (original) +++ geronimo/server/branches/2.1/plugins/system-database/sysdb- portlets/src/main/java/org/apache/geronimo/console/internaldb/ DBViewerHelper.java Mon Sep 29 11:09:17 2008 @@ -18,9 +18,20 @@ package org.apache.geronimo.console.internaldb; import java.io.File; +import java.util.ArrayList; import java.util.Collection; +import java.util.List; import java.util.Vector; +import org.apache.geronimo.console.util.KernelManagementHelper; +import org.apache.geronimo.console.util.ManagementHelper; +import org.apache.geronimo.console.util.PortletManager; +import org.apache.geronimo.gbean.AbstractName; +import org.apache.geronimo.j2ee.j2eeobjectnames.NameFactory; +import org.apache.geronimo.kernel.Kernel; +import org.apache.geronimo.kernel.KernelRegistry; +import org.apache.geronimo.management.geronimo.ResourceAdapterModule; + public class DBViewerHelper { private static final String SYS_TBL_PREFIX = "SYS."; @@ -28,6 +39,34 @@ private static final int COUNT_COL = 1; /** + * List the databases having datasources deployed. + * + * @param derbySysHome + * @return + */ +public Collection getDataSourceNames() { + + List databaseNames = new ArrayList(); + +Kernel kernel = KernelRegistry.getSingleKernel(); +ManagementHelper helper = new KernelManagementHelper(kernel); +ResourceAdapterModule[] modules = helper.getOutboundRAModules(helper.getDomains() [0].getServerInstances()[0], "javax.sql.DataSource"); +for (ResourceAdapterModule module : modules) { + org .apache.geronimo.management.geronimo.JCA
[BUILD] trunk: Failed for Revision: 750107
Geronimo Revision: 750107 built with tests included See the full build-1500.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/build-1500.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 37 minutes 16 seconds [INFO] Finished at: Wed Mar 04 15:44:36 EST 2009 [INFO] Final Memory: 397M/1002M [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/20090304/logs-1500-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-1500-jetty/test.log [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:46.158 [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 36 test builds [INFO] [INFO] --- [INFO] [INFO] commands-testsuite/deploy RUNNING [INFO] commands-testsuite/deploy SUCCESS (0:01:11.038) [INFO] commands-testsuite/gshell RUNNING [INFO] commands-testsuite/gshell SUCCESS (0:00:30.497) [INFO] commands-testsuite/jaxws RUNNING [INFO] commands-testsuite/jaxws SUCCESS (0:00:34.506) [INFO] commands-testsuite/shutdownRUNNING [INFO] commands-testsuite/shutdownSUCCESS (0:00:16.092) [INFO] concurrent-testsuite/concurrent-basic RUNNING [INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:06.510) [INFO] console-testsuite/advanced RUNNING [INFO] console-testsuite/advanced FAILURE (0:00:16.875) Java returned: 1 [INFO] console-testsuite/basicRUNNING [INFO] console-testsuite/basicFAILURE (0:00:18.150) Java returned: 1 [INFO] corba-testsuite/corba-helloworld RUNNING [INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:46.796) [INFO] corba-testsuite/corba-marshal RUNNING [INFO] corba-testsuite/corba-marshal SUCCESS (0:01:02.903) [INFO] corba-testsuite/corba-mytime RUNNING [INFO] corba-testsuite/corba-mytime SUCCESS (0:00:39.364) [INFO] deployment-testsuite/deployment-tests RUNNING [INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:30.710) [INFO] deployment-testsuite/jca-cms-tests RUNNING [INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:30.649) [INFO] deployment-testsuite/manifestcp-tests RUNNING [INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:32.739) [INFO] enterprise-testsuite/ejb-tests RUNNING [INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:36.588) [INFO] enterprise-testsuite/jms-tests RUNNING [INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:51.113) [INFO] enterprise-testsuite/jpa-tests RUNNING [INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:41.207) [INFO] enterprise-testsuite/sec-clientRUNNING [INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:28.274) [INFO] enterprise-testsuite/sec-tests RUNNING [INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.310) [INFO] security-testsuite/test-security RUNNING [INFO] security-testsuite/test-security FAILURE (0:00:34.391) Java returned: 1 [INFO] web-testsuite/test-2.1-jspsRUNNING [INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.060) [INFO] web-testsuite/test-2.5-servletsRUNNING [INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00
Re: svn commit: r700193 - in /geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main: java/org/apache/geronimo/console/internaldb/ resources/ webapp/WEB-INF/view/internaldb/
I know this is going way back in time ... but any idea why this change deleted the content of dbViewerMaximized.jsp but kept the empty file around? I discovered this when checking for source headers. This file is flagged because it doesn't contain a header - but more than that it doesn't contain anything at all. I presume we can delete the entire file. Does anybody know of any reason why we should not do this? There are a few other instances of similar files that we need to deal with as well. Joe dwo...@apache.org wrote: Author: dwoods Date: Mon Sep 29 11:09:17 2008 New Revision: 700193 URL: http://svn.apache.org/viewvc?rev=700193&view=rev Log: GERONIMO-4225 Allow Run SQL portlet run sql against any configured data source. Thanks to Michal Borowiecki for the patch. Added: geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/listDatabasesMaximized.jsp (with props) geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/listTablesMaximized.jsp (with props) geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/viewTableContentsMaximized.jsp (with props) Modified: geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerPortlet.java geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DerbyConnectionUtil.java geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/RunSQLHelper.java geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/RunSQLPortlet.java geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/resources/systemdatabase.properties geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/dbViewerMaximized.jsp geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/webapp/WEB-INF/view/internaldb/runSQLNormal.jsp Modified: geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java?rev=700193&r1=700192&r2=700193&view=diff == --- geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java (original) +++ geronimo/server/branches/2.1/plugins/system-database/sysdb-portlets/src/main/java/org/apache/geronimo/console/internaldb/DBViewerHelper.java Mon Sep 29 11:09:17 2008 @@ -18,9 +18,20 @@ package org.apache.geronimo.console.internaldb; import java.io.File; +import java.util.ArrayList; import java.util.Collection; +import java.util.List; import java.util.Vector; +import org.apache.geronimo.console.util.KernelManagementHelper; +import org.apache.geronimo.console.util.ManagementHelper; +import org.apache.geronimo.console.util.PortletManager; +import org.apache.geronimo.gbean.AbstractName; +import org.apache.geronimo.j2ee.j2eeobjectnames.NameFactory; +import org.apache.geronimo.kernel.Kernel; +import org.apache.geronimo.kernel.KernelRegistry; +import org.apache.geronimo.management.geronimo.ResourceAdapterModule; + public class DBViewerHelper { private static final String SYS_TBL_PREFIX = "SYS."; @@ -28,6 +39,34 @@ private static final int COUNT_COL = 1; /** + * List the databases having datasources deployed. + * + * @param derbySysHome + * @return + */ +public Collection getDataSourceNames() { + + List databaseNames = new ArrayList(); + +Kernel kernel = KernelRegistry.getSingleKernel(); +ManagementHelper helper = new KernelManagementHelper(kernel); +ResourceAdapterModule[] modules = helper.getOutboundRAModules(helper.getDomains()[0].getServerInstances()[0], "javax.sql.DataSource"); +for (ResourceAdapterModule module : modules) { +org.apache.geronimo.management.geronimo.JCAManagedConnectionFactory[] databases = helper.getOutboundFactories(module, "javax.sql.DataSource"); +for (org.apache.geronimo.management.geronimo.JCAManagedConnectionFactory db : databases) { +try { +AbstractName dbName = kernel.getAbstractNameFor(db); +String datasourceName = (String)dbName.getName().get(
[jira] Closed: (GERONIMO-4538) Make framework self contained to build the framework server
[ https://issues.apache.org/jira/browse/GERONIMO-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4538. -- Resolution: Fixed Doesn't seem to break anything. > Make framework self contained to build the framework server > --- > > Key: GERONIMO-4538 > URL: https://issues.apache.org/jira/browse/GERONIMO-4538 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > Make everything needed to build the framework server be in framework. This > should make it a lot easier to experiment with the framework server because > you have a lot less to build. > It should have its own testsuite, although that may be added later. > I don't plan to change any groupIds or artifactIds immediately although some > should probably be modified slightly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4569) Built sample plugin by using new tomcat6-deployer cannot be installed on server
[ https://issues.apache.org/jira/browse/GERONIMO-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4569. -- Resolution: Fixed I reverted my changes from the other bug. In the future please do not proliferate bugs reports for the same issue but just attach comments to the original issue. > Built sample plugin by using new tomcat6-deployer cannot be installed on > server > --- > > Key: GERONIMO-4569 > URL: https://issues.apache.org/jira/browse/GERONIMO-4569 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 2.1.4 >Reporter: Forrest Xia >Assignee: David Jencks >Priority: Critical > > Recently, when I am building some 2.1 branch samples plugins, I found that > built sample plugins are all not installable. > A message on admin console like this: > "A problem has occured: > org.apache.geronimo.kernel.config.LifecycleException: start of > org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed" > An exception in stdout/stderr like this: > "Caused by: > org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve > reference "Container" in gbean > org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT > to a gbean matching the pattern [?name=WebContainer#] > at > org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)" > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4566) Need extra servlet mappings for jetty for welcome jsps compiled into servlets
[ https://issues.apache.org/jira/browse/GERONIMO-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678870#action_12678870 ] David Jencks commented on GERONIMO-4566: re-included the jsps since jetty may not fix this soon and the servlet mapping doesn't seem to actually work reliably. rev 750118. > Need extra servlet mappings for jetty for welcome jsps compiled into servlets > - > > Key: GERONIMO-4566 > URL: https://issues.apache.org/jira/browse/GERONIMO-4566 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: David Jencks >Assignee: David Jencks > > See http://jira.codehaus.org/browse/JETTY-936. We need to include at least a > servlet mapping something like: > > jsp.index_jsp > / > > until jetty fixes the default servlet. > This showed up because I deleted the uncompiled jsps. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter
[ https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678864#action_12678864 ] Joe Bohn commented on GERONIMO-4549: Perhaps I don't fully understand the problem ... but I attempted to recreate it and in my case the jndi entry was removed. I did the following: - selected Services->JMS Resources from the navigation - created a new resource group for ActiveMQ as follows: - specified a group of myRG and kept the defaults for all else - created a new connection factory under the Resource Group called myFactory and kept the defaults for all else - deployed the plan - validated that the resource group was running and visible in the JMS Resources view, the J2EE Connectors view (and running) and the JNDI viewer under ResourceAdapterModule - from the J2EE Connectors view I uninstalled my resource group rar - It was removed from the J2EE Connectors view, the JMS Resources view, and the JNDI Viewer Am I completely missing the issue? > JMS resource jndi entries are not removed after uninstalling the JMS connect > adapter > > > Key: GERONIMO-4549 > URL: https://issues.apache.org/jira/browse/GERONIMO-4549 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.1.4 >Reporter: Forrest Xia >Priority: Blocker > Fix For: 2.1.4, 2.2 > > > Steps to reproduce this problem: > 1. login admin console > 2. Create a ActiveMQ resource connector with the wizard > 3. Deploy it and check it is in running state > 4. Click J2EE connector to uninstall it > 5. Check JNDI viewer, you will see the JNDI entry still there, even you've > uninstalled it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cron /home/jdillon/ws/site/bin/sync
Joe, I am very sure that I did that step, as I still have the terminal window from yesterday pm - Play nice. -- ASF Infrastructure (infrastruct...@apache.org) [lin...@minotaur ~]$ chgrp -R geronimo public_html/staging-site/txmanager [lin...@minotaur ~]$ pwd /home/linsun [lin...@minotaur ~]$ chmod -R g+w public_html/staging-site/txmanager [lin...@minotaur ~]$ ls public_html/staging-site/txmanager 2.1.2 [lin...@minotaur ~]$ cp -r public_html/staging-site/txmanager /www/geronimo.apache.org/maven I also found out that the two directories have different permission after the cp command: drwxrwxr-x public_html/staging-site/txmanager drwxr-xr-x /www/geronimo.apache.org/maven/txmanager Maybe it worked on your machine but I had to have the last step. Lin On Wed, Mar 4, 2009 at 1:46 PM, Joe Bohn wrote: > > Lin, > > The new step you added (after the copy) should not be necessary if you had > performed the step immediately prior to the copy (chmod -R g+w > public_html/staging-site/[siteId]). Are you sure you didn't just skip that > step by mistake? > > Regards, > Joe > - Show quoted text - > > > > Lin Sun wrote: >> >> I hope I resolved this.. I also updated the component release wiki >> page for the step I missed. >> >> Thanks. >> >> Lin >> >> On Wed, Mar 4, 2009 at 9:15 AM, Jason Dillon wrote: >>> >>> Some permission problems... >>> --jason >>> >>> Begin forwarded message: >>> >>> From: jdil...@apache.org (Cron Daemon) >>> Date: March 4, 2009 9:08:11 PM GMT+07:00 >>> To: jdil...@apache.org >>> Subject: Cron /home/jdillon/ws/site/bin/sync >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/logos/maven-feather.png: >>> Operation not permitted >>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/logos: >>> Operation not permitted >>> chmod: >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/external.png: >>> Operation not permitted >>> chmod: >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_error_sml.gif: >>> Operation not permitted >>> chmod: >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_info_sml.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_success_sml.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/icon_warning_sml.gif: >>> Operation not permitted >>> chmod: >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/newwindow.png: >>> Operation not permitted >>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images/spacer.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/top_bgstretch_1x64.gif: >>> Operation not permitted >>> chmod: >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/border_bottom.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/images/topleft_logo_437x64.gif: >>> Operation not permitted >>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/images: Operation >>> not >>> permitted >>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css/maven-base.css: >>> Operation not permitted >>> chmod: >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/css/maven-theme.css: >>> Operation not permitted >>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css/print.css: >>> Operation not permitted >>> chmod: /www/geronimo.apache.org/maven/txmanager/2.1.2/css: Operation not >>> permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/logos/maven-feather.png: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/logos: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/external.png: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_error_sml.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_info_sml.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_success_sml.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/icon_warning_sml.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/newwindow.png: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/spacer.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/top_bgstretch_1x64.gif: >>> Operation not permitted >>> chmod: >>> >>> /www/geronimo.apache.org/maven/txmanager/2.1.2/geronimo-transaction/images/border_bottom.gif: >>> Operatio
[jira] Assigned: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-4554: - Assignee: Jarek Gawor (was: David Jencks) > Cant deploy an ejb web service as a plugin using car-maven-plugin > - > > Key: GERONIMO-4554 > URL: https://issues.apache.org/jira/browse/GERONIMO-4554 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.3 >Reporter: David Jencks >Assignee: Jarek Gawor > Fix For: 2.1.4, 2.2 > > > I tried to deploy an ejb web service using the car-maven-plugin. The cxf and > axis2 ejb deployers set up the wslink gbean with a reference to the web > container. This is set in the plan for the deployers as "WebContainer" but > the geronimo-plugin.xml overrides this to "${webContainer}". The jetty and > tomcat plugins use a config-substitutions entry to e.g. set > webContainer=JettyWebContainer > So, this all works on a server where all the plugins are installed. However > it doesn't work when using the car-maven-plugin since the config.xml > overrides and config-substitutions are not applied. > We need to either make the config modifications work for the car-maven-plugin > or make sure none of the deployers the car-maven-plugin might use depend on > these customizations to work. For instance, we could change all the names to > WebContainer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3907: --- Priority: Minor (was: Blocker) I have updated the status of this problem to "minor" from "blocker" because it appears that the original issue (no error returned) has been resolved. The remaining issue seems to be the detail of the error reported. Are there any additional enhancements planned for this JIRA in this area? If not, we should close this issue. Actually, since the core problem has been resolved we should perhaps close the issue and open a new issue requesting the enhancement. If there are no additional enhancements planned for Geronimo 2.1.4 we should remove it from the fix versions. It appears that the original problem was fixed in 2.1.1. > Persistence Exception is not visible/lost for client. > -- > > Key: GERONIMO-3907 > URL: https://issues.apache.org/jira/browse/GERONIMO-3907 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.0.2, 2.1 > Environment: Linux, Windows >Reporter: Ralf Baumhof >Assignee: David Jencks >Priority: Minor > Fix For: 2.1.4, 2.2 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > I am trying an insert on a table. The Entity class is wrong annotated, one > column was renamed in the table. Then the following situation occurs. > The call to persist(entity) is successfully, no exception is thrown. On > leaving the ejb container and returning to tomact a commit is performed (it's > a managed datasource, so container performs commit). This leads to the insert > on database. This insert fails, a rollback is performed. On return to the JSF > bean no exception can be seen by the bean. In the same class i have got a > query method. If i replace the call to persist with the call to the query > method everything works ok. The exception is thrown and is visible at the > client site. > This is the geronimo console output. The last line comes from the JSB bean > which reports a successful insert. > 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; > transaction will roll back > > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) > at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) > at > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) > at > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) > at > org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) > at > org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) > at > org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) > at > org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) > at > org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) > at $Proxy75.anlegenBenutzer(Unknown Source) > at > de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) >
[jira] Commented: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678799#action_12678799 ] David Jencks commented on GERONIMO-4554: Reverted changes from rev 748420 and 748924 in rev 750081 My next idea to fix this is to give the ejb web service deployers sets of abstract name queries so they can find either the jetty or tomcat web container. You won't be able to run both jetty and tomcat on the same server if you have ejb web services, but I dont think that is a major limitation. > Cant deploy an ejb web service as a plugin using car-maven-plugin > - > > Key: GERONIMO-4554 > URL: https://issues.apache.org/jira/browse/GERONIMO-4554 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.3 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1.4, 2.2 > > > I tried to deploy an ejb web service using the car-maven-plugin. The cxf and > axis2 ejb deployers set up the wslink gbean with a reference to the web > container. This is set in the plan for the deployers as "WebContainer" but > the geronimo-plugin.xml overrides this to "${webContainer}". The jetty and > tomcat plugins use a config-substitutions entry to e.g. set > webContainer=JettyWebContainer > So, this all works on a server where all the plugins are installed. However > it doesn't work when using the car-maven-plugin since the config.xml > overrides and config-substitutions are not applied. > We need to either make the config modifications work for the car-maven-plugin > or make sure none of the deployers the car-maven-plugin might use depend on > these customizations to work. For instance, we could change all the names to > WebContainer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?
+1. I agree that would be an acceptable limitation. Joe David Jencks wrote: On Mar 4, 2009, at 8:39 AM, Joe Bohn wrote: Forrest, Thanks for finding this problem and raising the issue. IMO this is a critical issue that breaks backward compatibility. I had validated that our 2.1.2 samples installed and worked in our 2.1.4 server image prior to this change. Since this change has been made this is no longer true. I suspect this will also break other component installations (such as directory) and perhaps user created components. We need another solution that support backward compatibility. I guess we need to revert my attempt to fix the original problem. Maybe we can change the ejb-webservice deployers to use two abstract name queries that will pick up either the jetty or tomcat web container. That would only prevent people from running both jetty and tomcat at once if they have ejb web services maybe not a serious limitation. david jencks Joe Jarek Gawor wrote: Please see https://issues.apache.org/jira/browse/GERONIMO-4554. Jarek On Wed, Mar 4, 2009 at 11:14 AM, Forrest_Xia wrote: Recently, when I am building some 2.1 branch samples plugins, I found that built sample plugins are all not installable. A message on admin console like this: "A problem has occured: org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed" An exception in stdout/stderr like this: "Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference "Container" in gbean org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT to a gbean matching the pattern [?name=WebContainer#] at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)" After some research, I found someone changed tomcat6-deployer plugin deployment plan, changed "TomcatWebBuilder" GBean's attribute "tomcatContainerName" value from "?name=TomcatWebContainer" to "?name=WebContainer", why did that? However, I think that's the reason causing the built plugins uninstallable. Please help review and see if it is a bug before 2.1.4 release. Thanks! Forrest -- View this message in context: http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?
On Mar 4, 2009, at 11:50 AM, David Jencks wrote: On Mar 4, 2009, at 8:39 AM, Joe Bohn wrote: Forrest, Thanks for finding this problem and raising the issue. IMO this is a critical issue that breaks backward compatibility. I had validated that our 2.1.2 samples installed and worked in our 2.1.4 server image prior to this change. Since this change has been made this is no longer true. I suspect this will also break other component installations (such as directory) and perhaps user created components. We need another solution that support backward compatibility. I guess we need to revert my attempt to fix the original problem. Maybe we can change the ejb-webservice deployers to use two abstract name queries that will pick up either the jetty or tomcat web container. That would only prevent people from running both jetty and tomcat at once if they have ejb web services maybe not a serious limitation. I'd agree that would not be a serious limitation. --kevan
Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?
On Mar 4, 2009, at 8:39 AM, Joe Bohn wrote: Forrest, Thanks for finding this problem and raising the issue. IMO this is a critical issue that breaks backward compatibility. I had validated that our 2.1.2 samples installed and worked in our 2.1.4 server image prior to this change. Since this change has been made this is no longer true. I suspect this will also break other component installations (such as directory) and perhaps user created components. We need another solution that support backward compatibility. I guess we need to revert my attempt to fix the original problem. Maybe we can change the ejb-webservice deployers to use two abstract name queries that will pick up either the jetty or tomcat web container. That would only prevent people from running both jetty and tomcat at once if they have ejb web services maybe not a serious limitation. david jencks Joe Jarek Gawor wrote: Please see https://issues.apache.org/jira/browse/GERONIMO-4554. Jarek On Wed, Mar 4, 2009 at 11:14 AM, Forrest_Xia wrote: Recently, when I am building some 2.1 branch samples plugins, I found that built sample plugins are all not installable. A message on admin console like this: "A problem has occured: org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed" An exception in stdout/stderr like this: "Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference "Container" in gbean org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car? J2EEApplication =null,j2eeType=WebModule,name=org.apache.geronimo.samples/ calculator-tomcat/2.1.3-SNAPSHOT to a gbean matching the pattern [?name=WebContainer#] at org .apache .geronimo .kernel .config .ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) at org .apache .geronimo .kernel .config .ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java: 438) at org .apache .geronimo .kernel .config .KernelConfigurationManager.start(KernelConfigurationManager.java: 188) at org .apache .geronimo .kernel .config .SimpleConfigurationManager .startConfiguration(SimpleConfigurationManager.java:562)" After some research, I found someone changed tomcat6-deployer plugin deployment plan, changed "TomcatWebBuilder" GBean's attribute "tomcatContainerName" value from "?name=TomcatWebContainer" to "?name=WebContainer", why did that? However, I think that's the reason causing the built plugins uninstallable. Please help review and see if it is a bug before 2.1.4 release. Thanks! Forrest -- View this message in context: http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?
Opened a defect https://issues.apache.org/jira/browse/GERONIMO-4569 Forrest Forrest_Xia wrote: > > I think this change bring another defect, that is built sample plugin > which uses tomcat6-deployer won't be able to install on the server. > > Please check. thanks! > > Forrest > -- View this message in context: http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22334092.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Created: (GERONIMO-4569) Built sample plugin by using new tomcat6-deployer cannot be installed on server
Built sample plugin by using new tomcat6-deployer cannot be installed on server --- Key: GERONIMO-4569 URL: https://issues.apache.org/jira/browse/GERONIMO-4569 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.1.4 Reporter: Forrest Xia Assignee: David Jencks Priority: Critical Recently, when I am building some 2.1 branch samples plugins, I found that built sample plugins are all not installable. A message on admin console like this: "A problem has occured: org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed" An exception in stdout/stderr like this: "Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference "Container" in gbean org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT to a gbean matching the pattern [?name=WebContainer#] at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678780#action_12678780 ] Joe Bohn commented on GERONIMO-4554: I agree with Forrest. This breaks backward compatibility and as such is not an acceptable change. > Cant deploy an ejb web service as a plugin using car-maven-plugin > - > > Key: GERONIMO-4554 > URL: https://issues.apache.org/jira/browse/GERONIMO-4554 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.3 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1.4, 2.2 > > > I tried to deploy an ejb web service using the car-maven-plugin. The cxf and > axis2 ejb deployers set up the wslink gbean with a reference to the web > container. This is set in the plan for the deployers as "WebContainer" but > the geronimo-plugin.xml overrides this to "${webContainer}". The jetty and > tomcat plugins use a config-substitutions entry to e.g. set > webContainer=JettyWebContainer > So, this all works on a server where all the plugins are installed. However > it doesn't work when using the car-maven-plugin since the config.xml > overrides and config-substitutions are not applied. > We need to either make the config modifications work for the car-maven-plugin > or make sure none of the deployers the car-maven-plugin might use depend on > these customizations to work. For instance, we could change all the names to > WebContainer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?
I think this change bring another defect, that is built sample plugin which uses tomcat6-deployer won't be able to install on the server. Please check. thanks! Forrest -- View this message in context: http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333917.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?
Forrest, Thanks for finding this problem and raising the issue. IMO this is a critical issue that breaks backward compatibility. I had validated that our 2.1.2 samples installed and worked in our 2.1.4 server image prior to this change. Since this change has been made this is no longer true. I suspect this will also break other component installations (such as directory) and perhaps user created components. We need another solution that support backward compatibility. Joe Jarek Gawor wrote: Please see https://issues.apache.org/jira/browse/GERONIMO-4554. Jarek On Wed, Mar 4, 2009 at 11:14 AM, Forrest_Xia wrote: Recently, when I am building some 2.1 branch samples plugins, I found that built sample plugins are all not installable. A message on admin console like this: "A problem has occured: org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed" An exception in stdout/stderr like this: "Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference "Container" in gbean org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT to a gbean matching the pattern [?name=WebContainer#] at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)" After some research, I found someone changed tomcat6-deployer plugin deployment plan, changed "TomcatWebBuilder" GBean's attribute "tomcatContainerName" value from "?name=TomcatWebContainer" to "?name=WebContainer", why did that? However, I think that's the reason causing the built plugins uninstallable. Please help review and see if it is a bug before 2.1.4 release. Thanks! Forrest -- View this message in context: http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMO-4554) Cant deploy an ejb web service as a plugin using car-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678776#action_12678776 ] Forrest Xia commented on GERONIMO-4554: --- I think these changes will make built server plugins which uses tomcat6-deployer failed to install on server. For details, please see http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--td22333212s134.html. Forrest > Cant deploy an ejb web service as a plugin using car-maven-plugin > - > > Key: GERONIMO-4554 > URL: https://issues.apache.org/jira/browse/GERONIMO-4554 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1.3 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1.4, 2.2 > > > I tried to deploy an ejb web service using the car-maven-plugin. The cxf and > axis2 ejb deployers set up the wslink gbean with a reference to the web > container. This is set in the plan for the deployers as "WebContainer" but > the geronimo-plugin.xml overrides this to "${webContainer}". The jetty and > tomcat plugins use a config-substitutions entry to e.g. set > webContainer=JettyWebContainer > So, this all works on a server where all the plugins are installed. However > it doesn't work when using the car-maven-plugin since the config.xml > overrides and config-substitutions are not applied. > We need to either make the config modifications work for the car-maven-plugin > or make sure none of the deployers the car-maven-plugin might use depend on > these customizations to work. For instance, we could change all the names to > WebContainer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?
Please see https://issues.apache.org/jira/browse/GERONIMO-4554. Jarek On Wed, Mar 4, 2009 at 11:14 AM, Forrest_Xia wrote: > > Recently, when I am building some 2.1 branch samples plugins, I found that > built sample plugins are all not installable. > A message on admin console like this: > "A problem has occured: > org.apache.geronimo.kernel.config.LifecycleException: start of > org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed" > > An exception in stdout/stderr like this: > "Caused by: > org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve > reference "Container" in gbean > org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT > to a gbean matching the pattern [?name=WebContainer#] > at > org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)" > > After some research, I found someone changed tomcat6-deployer plugin > deployment plan, changed "TomcatWebBuilder" GBean's attribute > "tomcatContainerName" value from "?name=TomcatWebContainer" to > "?name=WebContainer", why did that? > > However, I think that's the reason causing the built plugins uninstallable. > > Please help review and see if it is a bug before 2.1.4 release. Thanks! > > Forrest > > -- > View this message in context: > http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html > Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. > >
Why change tomcatContainerName from "?name=TomcatWebContainer" to "?name=WebContainer" in tomcat6-deployer plugin of 2.1.4-snapshot?
Recently, when I am building some 2.1 branch samples plugins, I found that built sample plugins are all not installable. A message on admin console like this: "A problem has occured: org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car failed" An exception in stdout/stderr like this: "Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unable to resolve reference "Container" in gbean org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.samples/calculator-tomcat/2.1.3-SNAPSHOT to a gbean matching the pattern [?name=WebContainer#] at org.apache.geronimo.kernel.config.ConfigurationUtil.preprocessGBeanData(ConfigurationUtil.java:380) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:438) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)" After some research, I found someone changed tomcat6-deployer plugin deployment plan, changed "TomcatWebBuilder" GBean's attribute "tomcatContainerName" value from "?name=TomcatWebContainer" to "?name=WebContainer", why did that? However, I think that's the reason causing the built plugins uninstallable. Please help review and see if it is a bug before 2.1.4 release. Thanks! Forrest -- View this message in context: http://www.nabble.com/Why-change-tomcatContainerName-from-%22-name%3DTomcatWebContainer%22-to-%22-name%3DWebContainer%22-in-tomcat6-deployer-plugin-of-2.1.4-snapshot--tp22333212s134p22333212.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Issue Comment Edited: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter
[ https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678767#action_12678767 ] caijunj edited comment on GERONIMO-4549 at 3/4/09 8:10 AM: So I spend more time to understand the code. Guess I now know the reason why Context A is chosen that way (to quickly remove a chain of subcontext which only contains the object to be removed). But I still don't get why removeNotEmptyContext is set to false in org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(). I propose 2 fixes as - 1. Update org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(), new code below (change false to removeNotEmptyContext) {code} protected boolean removeBinding(String name, boolean removeNotEmptyContext) throws NamingException { if (WritableContext.this.removeBinding(bindingsRef, name, removeNotEmptyContext)) { return true; } return super.removeBinding(name, removeNotEmptyContext); } {code} 2. Update the org.apache.xbean.naming.context.AbstractContext.removeDeepBinding() to remove the chain of subcontexts one by one starting from the leaf subcontexts, so that each subcontext IS empty when being removed and can thus be removed successfully even if removeNotEmptyContext is set to false. Any comments? I'll submit the patch tomorrow. But I'd like to get some advice beforehands. was (Author: caijunj): So I spend more time to understand the code. Guess I now know the reason why Context A is chosen that way (to quickly remove a chain of subcontext which only contains the object to be removed). But I still don't get why removeNotEmptyContext is set to false in org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(). I propose 2 fixes as - 1. Update org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(), new code below (change false to removeNotEmptyContext) {code} protected boolean removeBinding(String name, boolean removeNotEmptyContext) throws NamingException { if (WritableContext.this.removeBinding(bindingsRef, name, removeNotEmptyContext)) { return true; } return super.removeBinding(name, removeNotEmptyContext); } {/code} 2. Update the org.apache.xbean.naming.context.AbstractContext.removeDeepBinding() to remove the chain of subcontexts one by one starting from the leaf subcontexts, so that each subcontext IS empty when being removed and can thus be removed successfully even if removeNotEmptyContext is set to false. Any comments? I'll submit the patch tomorrow. But I'd like to get some advice beforehands. > JMS resource jndi entries are not removed after uninstalling the JMS connect > adapter > > > Key: GERONIMO-4549 > URL: https://issues.apache.org/jira/browse/GERONIMO-4549 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.1.4 >Reporter: Forrest Xia >Priority: Blocker > Fix For: 2.1.4, 2.2 > > > Steps to reproduce this problem: > 1. login admin console > 2. Create a ActiveMQ resource connector with the wizard > 3. Deploy it and check it is in running state > 4. Click J2EE connector to uninstall it > 5. Check JNDI viewer, you will see the JNDI entry still there, even you've > uninstalled it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [NOTICE] Creating server/branches/2.1.4
Since Donald has marked this JIRA [1] as a blocker, I'm keen to get it fixed in 2.1.4. I have two ideas which I described in the JIRA comments. Can anyone who are familiar with the xbean-naming code take a look? Thanks! -Jack [1] https://issues.apache.org/jira/browse/GERONIMO-4549 2009/3/4 Jarek Gawor > We discovered a problem in Axis2 1.3 that prevents web services with > overloaded methods to be deployed correctly. I would like to include a > fix for this problem in 2.1.4 and in order to do that I will need to > create patched versions of some of the Axis2 artifacts. I hope that's > ok with everybody. I should be able to get this done today if there > are no objections. > > Btw, this problem was already fixed in the latest Axis2 code so it > does not affect trunk. > > Thanks, > Jarek > > On Tue, Feb 24, 2009 at 2:30 PM, Joe Bohn wrote: > > We're getting very close to a Geronimo 2.1.4 release. I think it's > nearly > > time to create a branch to prepare for the release. > > > > So, I'm planning to create a branch on Thursday afternoon (2/26). > > > > Please carefully consider any changes in the branches/2.1 that might > > destabilize things and consider holding off until after the branch. I do > > anticipate that there will continue to be bug fixes and other minor > changes. > > Hopefully, we will be in a position to create a release candidate > sometime > > next week. > > > > Thanks, > > Joe > > >
[jira] Commented: (GERONIMO-4549) JMS resource jndi entries are not removed after uninstalling the JMS connect adapter
[ https://issues.apache.org/jira/browse/GERONIMO-4549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678767#action_12678767 ] Jack Cai commented on GERONIMO-4549: So I spend more time to understand the code. Guess I now know the reason why Context A is chosen that way (to quickly remove a chain of subcontext which only contains the object to be removed). But I still don't get why removeNotEmptyContext is set to false in org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(). I propose 2 fixes as - 1. Update org.apache.xbean.naming.context.WritableContext$NestedWritableContext.removeBinding(), new code below (change false to removeNotEmptyContext) {code} protected boolean removeBinding(String name, boolean removeNotEmptyContext) throws NamingException { if (WritableContext.this.removeBinding(bindingsRef, name, removeNotEmptyContext)) { return true; } return super.removeBinding(name, removeNotEmptyContext); } {/code} 2. Update the org.apache.xbean.naming.context.AbstractContext.removeDeepBinding() to remove the chain of subcontexts one by one starting from the leaf subcontexts, so that each subcontext IS empty when being removed and can thus be removed successfully even if removeNotEmptyContext is set to false. Any comments? I'll submit the patch tomorrow. But I'd like to get some advice beforehands. > JMS resource jndi entries are not removed after uninstalling the JMS connect > adapter > > > Key: GERONIMO-4549 > URL: https://issues.apache.org/jira/browse/GERONIMO-4549 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.1.4 >Reporter: Forrest Xia >Priority: Blocker > Fix For: 2.1.4, 2.2 > > > Steps to reproduce this problem: > 1. login admin console > 2. Create a ActiveMQ resource connector with the wizard > 3. Deploy it and check it is in running state > 4. Click J2EE connector to uninstall it > 5. Check JNDI viewer, you will see the JNDI entry still there, even you've > uninstalled it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4544) Error occured when repeatedly create DB or records
[ https://issues.apache.org/jira/browse/GERONIMO-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678762#action_12678762 ] Jarek Gawor commented on GERONIMO-4544: --- Yes, that makes sense. Sorry about missing that change. Added the conn.setAutoCommit(true) call to trunk (revision 750053) and branches/2.1 (revision 750054). > Error occured when repeatedly create DB or records > -- > > Key: GERONIMO-4544 > URL: https://issues.apache.org/jira/browse/GERONIMO-4544 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.4 > Environment: JAVA5 + RHEL 5.3 (X86) + Firefox 3.0.5 >Reporter: lily seattle >Assignee: Jarek Gawor > Fix For: 2.1.4, 2.2 > > Attachments: Geronimo-4544-for2.1.patch, Geronimo-4544-forTrunk.patch > > > steps: > 1. login console > 2. Click Embedded DB -> DB Manager. > 3. Filling the Create DB blank with TestDB, click Create. > 4.Create a table using: > CREATE TABLE CUSTOMER ( > ID INTEGER NOT NULL PRIMARY KEY, > NAMEVARCHAR(45), > BIRTHDATE DATE, > SSS_NO VARCHAR(25), > ADDRESS VARCHAR(60), > ANNUAL_SALARY DOUBLE, > LOAN_AMOUNT DOUBLE > ); > 5. Insert a record: > INSERT INTO CUSTOMER VALUES > (001,'hi','02/19/2009','111','somewhere',100,150); > Now, if create the same table again, or Insert the same record, errors will > occur. Also the Table can't be accessed > any more. -- 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: 749996
Geronimo Revision: 749996 built with tests included See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/build-0900.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 41 minutes 23 seconds [INFO] Finished at: Wed Mar 04 09:48:57 EST 2009 [INFO] Final Memory: 392M/955M [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/20090304/logs-0900-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-0900-jetty/test.log [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:44.871 [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 36 test builds [INFO] [INFO] --- [INFO] [INFO] commands-testsuite/deploy RUNNING [INFO] commands-testsuite/deploy SUCCESS (0:01:09.680) [INFO] commands-testsuite/gshell RUNNING [INFO] commands-testsuite/gshell SUCCESS (0:00:30.383) [INFO] commands-testsuite/jaxws RUNNING [INFO] commands-testsuite/jaxws SUCCESS (0:00:35.195) [INFO] commands-testsuite/shutdownRUNNING [INFO] commands-testsuite/shutdownSUCCESS (0:00:16.009) [INFO] concurrent-testsuite/concurrent-basic RUNNING [INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:05.214) [INFO] console-testsuite/advanced RUNNING [INFO] console-testsuite/advanced FAILURE (0:00:16.558) Java returned: 1 [INFO] console-testsuite/basicRUNNING [INFO] console-testsuite/basicFAILURE (0:00:17.460) Java returned: 1 [INFO] corba-testsuite/corba-helloworld RUNNING [INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:48.711) [INFO] corba-testsuite/corba-marshal RUNNING [INFO] corba-testsuite/corba-marshal SUCCESS (0:00:49.113) [INFO] corba-testsuite/corba-mytime RUNNING [INFO] corba-testsuite/corba-mytime SUCCESS (0:00:39.815) [INFO] deployment-testsuite/deployment-tests RUNNING [INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:30.369) [INFO] deployment-testsuite/jca-cms-tests RUNNING [INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.521) [INFO] deployment-testsuite/manifestcp-tests RUNNING [INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:32.146) [INFO] enterprise-testsuite/ejb-tests RUNNING [INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:35.711) [INFO] enterprise-testsuite/jms-tests RUNNING [INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:51.497) [INFO] enterprise-testsuite/jpa-tests RUNNING [INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:40.495) [INFO] enterprise-testsuite/sec-clientRUNNING [INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:27.202) [INFO] enterprise-testsuite/sec-tests RUNNING [INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:47.145) [INFO] security-testsuite/test-security RUNNING [INFO] security-testsuite/test-security FAILURE (0:00:34.679) Java returned: 1 [INFO] web-testsuite/test-2.1-jspsRUNNING [INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:29.497) [INFO] web-testsuite/test-2.5-servletsRUNNING [INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00:28.352) [INFO] web-testsuite/test-jetty RUNNING [INFO] web-testsuite/test-jetty
[jira] Updated: (GERONIMO-4507) Admin console should honor the priority of user agent's language setting
[ https://issues.apache.org/jira/browse/GERONIMO-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4507: --- Attachment: locale-priority_fix2.patch > Admin console should honor the priority of user agent's language setting > > > Key: GERONIMO-4507 > URL: https://issues.apache.org/jira/browse/GERONIMO-4507 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.3, 2.2 > Environment: All >Reporter: Jack Cai >Assignee: Donald Woods >Priority: Minor > Fix For: 2.1.4, 2.2 > > Attachments: locale-priority.patch, locale-priority_fix.patch, > locale-priority_fix2.patch, locale-priority_V21.patch > > > See discussion: > http://www.nabble.com/Geronimo-Console-tp21369352s134p21383628.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4507) Admin console should honor the priority of user agent's language setting
[ https://issues.apache.org/jira/browse/GERONIMO-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4507: --- Attachment: (was: locale-priority_fix2.patch) > Admin console should honor the priority of user agent's language setting > > > Key: GERONIMO-4507 > URL: https://issues.apache.org/jira/browse/GERONIMO-4507 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.3, 2.2 > Environment: All >Reporter: Jack Cai >Assignee: Donald Woods >Priority: Minor > Fix For: 2.1.4, 2.2 > > Attachments: locale-priority.patch, locale-priority_fix.patch, > locale-priority_fix2.patch, locale-priority_V21.patch > > > See discussion: > http://www.nabble.com/Geronimo-Console-tp21369352s134p21383628.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4550) No error message displays in console when fail to create jms resource
[ https://issues.apache.org/jira/browse/GERONIMO-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4550: --- Attachment: fix-g4550-v22-jeffyin.patch Patch for geronimo v2.2 > No error message displays in console when fail to create jms resource > - > > Key: GERONIMO-4550 > URL: https://issues.apache.org/jira/browse/GERONIMO-4550 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.4 > Environment: OS:redhat 5.2 JDK 1.5 >Reporter: viola.lu >Assignee: Gang Yin >Priority: Minor > Attachments: fix-g4550-jeffyin.patch, fix-g4550-v22-jeffyin.patch, > screenshot-1.jpg, screenshot-2.jpg > > > 1.Create a console.jms/org.ibm.samples/1.0/rar resouce from admin console > 2.Receate a console.jms/org.ibm.samples/1.0/rar resource , but no error in > conosle but error message in geronimo.out :Deployer operation failed: Module > console.jms/org.ibm.samples/1.0/rar already exists in the server. Try to > undeploy it first or use the redeploy command. > 3.So no error message when fail to create a jms resource. -- 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: 749927
Geronimo Revision: 749927 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 41 minutes 8 seconds [INFO] Finished at: Wed Mar 04 03:46:24 EST 2009 [INFO] Final Memory: 428M/972M [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/20090304/logs-0300-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090304/logs-0300-jetty/test.log [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:47.442 [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 36 test builds [INFO] [INFO] --- [INFO] [INFO] commands-testsuite/deploy RUNNING [INFO] commands-testsuite/deploy SUCCESS (0:01:09.434) [INFO] commands-testsuite/gshell RUNNING [INFO] commands-testsuite/gshell SUCCESS (0:00:30.901) [INFO] commands-testsuite/jaxws RUNNING [INFO] commands-testsuite/jaxws SUCCESS (0:00:35.042) [INFO] commands-testsuite/shutdownRUNNING [INFO] commands-testsuite/shutdownSUCCESS (0:00:16.734) [INFO] concurrent-testsuite/concurrent-basic RUNNING [INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:08.076) [INFO] console-testsuite/advanced RUNNING [INFO] console-testsuite/advanced FAILURE (0:00:17.556) Java returned: 1 [INFO] console-testsuite/basicRUNNING [INFO] console-testsuite/basicFAILURE (0:00:17.874) Java returned: 1 [INFO] corba-testsuite/corba-helloworld RUNNING [INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:49.636) [INFO] corba-testsuite/corba-marshal RUNNING [INFO] corba-testsuite/corba-marshal SUCCESS (0:01:00.042) [INFO] corba-testsuite/corba-mytime RUNNING [INFO] corba-testsuite/corba-mytime SUCCESS (0:00:40.479) [INFO] deployment-testsuite/deployment-tests RUNNING [INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:29.735) [INFO] deployment-testsuite/jca-cms-tests RUNNING [INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:28.967) [INFO] deployment-testsuite/manifestcp-tests RUNNING [INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:31.306) [INFO] enterprise-testsuite/ejb-tests RUNNING [INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:36.000) [INFO] enterprise-testsuite/jms-tests RUNNING [INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:53.594) [INFO] enterprise-testsuite/jpa-tests RUNNING [INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:41.013) [INFO] enterprise-testsuite/sec-clientRUNNING [INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:28.376) [INFO] enterprise-testsuite/sec-tests RUNNING [INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.441) [INFO] security-testsuite/test-security RUNNING [INFO] security-testsuite/test-security FAILURE (0:00:34.091) Java returned: 1 [INFO] web-testsuite/test-2.1-jspsRUNNING [INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:28.857) [INFO] web-testsuite/test-2.5-servletsRUNNING [INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00
[jira] Created: (GERONIMO-4568) could not stop the application EAR that has the wrong JMS deployment plan
could not stop the application EAR that has the wrong JMS deployment plan - Key: GERONIMO-4568 URL: https://issues.apache.org/jira/browse/GERONIMO-4568 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.1.4 Environment: operating system: AIX Reporter: running Wang deploy the ear with the wrong JMS deployment plan could not stop the application via the console -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-555) Generated geronimo-plugin.xml file is empy after converting application to plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678640#action_12678640 ] viola.lu edited comment on GERONIMODEVTOOLS-555 at 3/4/09 12:50 AM: in jdk .16 , it doesn't work, but work on 1.5 was (Author: viola.lu): in jdk .16 , it doesn't work, but work on .15 > Generated geronimo-plugin.xml file is empy after converting application to > plugin > -- > > Key: GERONIMODEVTOOLS-555 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 > Environment: SunJDk 1.6 >Reporter: viola.lu >Assignee: Tim McConnell > > 1.Install GEP 2.2 snapshot on eclispe, start G2.2snapshot in it. > 2.Open defined server, and launch convert apps to plugins > 3.Choose deployed app cviewer and conver it to plugin, successfully saved > ,but check geronimo-plugin.xml, it's empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-555) Generated geronimo-plugin.xml file is empy after converting application to plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMODEVTOOLS-555: -- Environment: SunJDk 1.6 (was: SunJDk 1.5, 1.6) > Generated geronimo-plugin.xml file is empy after converting application to > plugin > -- > > Key: GERONIMODEVTOOLS-555 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 > Environment: SunJDk 1.6 >Reporter: viola.lu >Assignee: Tim McConnell > > 1.Install GEP 2.2 snapshot on eclispe, start G2.2snapshot in it. > 2.Open defined server, and launch convert apps to plugins > 3.Choose deployed app cviewer and conver it to plugin, successfully saved > ,but check geronimo-plugin.xml, it's empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-555) Generated geronimo-plugin.xml file is empy after converting application to plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678640#action_12678640 ] viola.lu commented on GERONIMODEVTOOLS-555: --- in jdk .16 , it doesn't work, but work on .15 > Generated geronimo-plugin.xml file is empy after converting application to > plugin > -- > > Key: GERONIMODEVTOOLS-555 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 > Environment: SunJDk 1.6 >Reporter: viola.lu >Assignee: Tim McConnell > > 1.Install GEP 2.2 snapshot on eclispe, start G2.2snapshot in it. > 2.Open defined server, and launch convert apps to plugins > 3.Choose deployed app cviewer and conver it to plugin, successfully saved > ,but check geronimo-plugin.xml, it's empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4567) Gshell deploy/assemble command on a remote server cannot work
Gshell deploy/assemble command on a remote server cannot work - Key: GERONIMO-4567 URL: https://issues.apache.org/jira/browse/GERONIMO-4567 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.4 Environment: remote : JAVA5 + SOLARIS 10 SPARC (32BIT) local : Windows xp professional sp3 Reporter: caiwenjing 1.Change the RemoteDeployHostname to the remote machine's IP in file var/config/config-substitutions.properties in the remote machine. 2.Add the remote machine's IP to /etc/hosts in the remote machine. 2.Start the server on the remote machine. 3.Cd into /bin directory on the local machine, launch gsh and run: deploy/connect -s REMOTE_IP -p PORT 4.run: deploy/assemble, input a server artifact name Then console shows: ERROR UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.ElementNSImpl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4566) Need extra servlet mappings for jetty for welcome jsps compiled into servlets
Need extra servlet mappings for jetty for welcome jsps compiled into servlets - Key: GERONIMO-4566 URL: https://issues.apache.org/jira/browse/GERONIMO-4566 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: David Jencks Assignee: David Jencks See http://jira.codehaus.org/browse/JETTY-936. We need to include at least a servlet mapping something like: jsp.index_jsp / until jetty fixes the default servlet. This showed up because I deleted the uncompiled jsps. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.