[jira] Created: (GERONIMO-4406) when client.bat/sh a non-exist project, return a error msg instead of a Exception stack log to user
when client.bat/sh a non-exist project, return a error msg instead of a Exception stack log to user Key: GERONIMO-4406 URL: https://issues.apache.org/jira/browse/GERONIMO-4406 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: Rex Wang D:\_w\wr\wasce-server-2.1.1.1\binclient.bat abc//1.1/car Using GERONIMO_BASE: D:\_w\wr\wasce-server-2.1.1.1 Using GERONIMO_HOME: D:\_w\wr\wasce-server-2.1.1.1 Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:D:\DevJava\Java\jdk1.5.0_15\jre Client Build: V2.1.1.1-20081017 Java Version: 1.5.0_15 13:11:11,234 ERROR [CommandLine] Client failed with exception: org.apache.geronimo.kernel.config.LifecycleException: load of abc//1.1/car f ailed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf iguration(SimpleConfigurationManager.java:276) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl ectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:832) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:96) at org.apache.geronimo.system.main.CommandLine.loadConfigurations(Comman dLine.java:192) at org.apache.geronimo.system.main.CommandLine.invokeMainGBean(CommandLi ne.java:100) at org.apache.geronimo.system.main.ClientCommandLine.startClient(ClientC ommandLine.java:84) at org.apache.geronimo.system.main.ClientCommandLine.execute(ClientComma ndLine.java:70) at org.apache.geronimo.system.main.EmbeddedClientCommandLine.execute(Emb eddedClientCommandLine.java:43) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma inConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.client.ClientCLI.main(ClientCLI.java:30) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: abc//1.1 /car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf igurationData(SimpleConfigurationManager.java:489) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConf iguration(SimpleConfigurationManager.java:273) ... 15 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4404) ActiveMQ connectors should use ServerHostname from config-substitutions.properties
[
https://issues.apache.org/jira/browse/GERONIMO-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang updated GERONIMO-4404:
--
Attachment: G4404_branch21.patch
This is the patch to 2.1 branch.
ActiveMQ connectors should use ServerHostname from
config-substitutions.properties
--
Key: GERONIMO-4404
URL: https://issues.apache.org/jira/browse/GERONIMO-4404
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.1.3
Reporter: Donald Woods
Priority: Minor
Fix For: 2.1.4
Attachments: G4404_branch21.patch, G4404_truck.patch
Ron Staerker reported that if you change ServerHostname in
config-substitutions.properties from 0.0.0.0 to 127.0.0.1, the default
ActiveMQ connectors on 61613 and 61616 will still bind to 0.0.0.0 instead of
the new ServerHostname value. This seems to b caused by several pom.xml
problems, where:
config-property-setting
name=ServerUrltcp://${PlanServerHostname}:${PlanActiveMQPort}/config-property-setting
where PlanServerHostname is 0.0.0.0 and not in config-substitutions.properties
attribute name=host#{ServerHostname}/attribute
is being substituted in at build time to be 0.0.0.0 instead of putting
${ServerHostname} in the plans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4404) ActiveMQ connectors should use ServerHostname from config-substitutions.properties
[
https://issues.apache.org/jira/browse/GERONIMO-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang updated GERONIMO-4404:
--
Attachment: G4404_truck.patch
Since activemq means to be used as standalone server. it's reasonable to them
to amplify localhost to 0.0.0.0 to make sure the activemq is reachable if the
user set the host other than 127.0.0.1.
If so , we can force the localhost to 127.0.0.1 in geronimo side as a
workaround. This is the patch to truck code. Please review, thanks.
ActiveMQ connectors should use ServerHostname from
config-substitutions.properties
--
Key: GERONIMO-4404
URL: https://issues.apache.org/jira/browse/GERONIMO-4404
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.1.3
Reporter: Donald Woods
Priority: Minor
Fix For: 2.1.4
Attachments: G4404_branch21.patch, G4404_truck.patch
Ron Staerker reported that if you change ServerHostname in
config-substitutions.properties from 0.0.0.0 to 127.0.0.1, the default
ActiveMQ connectors on 61613 and 61616 will still bind to 0.0.0.0 instead of
the new ServerHostname value. This seems to b caused by several pom.xml
problems, where:
config-property-setting
name=ServerUrltcp://${PlanServerHostname}:${PlanActiveMQPort}/config-property-setting
where PlanServerHostname is 0.0.0.0 and not in config-substitutions.properties
attribute name=host#{ServerHostname}/attribute
is being substituted in at build time to be 0.0.0.0 instead of putting
${ServerHostname} in the plans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 2.2 (trunk) bucket-o-snapshots
On 12/11/2008, at 10:04 AM, Joe Bohn wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid- December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? I will release WADI 2.1 whenever a release version is required for Geronimo. Thanks, Gianny
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646902#action_12646902 ] Joe Bohn commented on GERONIMO-4369: Thanks for the patch. I haven't looked into the problem or potential solutions much yet, but I did give your patch a try. Unfortunately, it results in some test failures during the build: Failed tests: testRestart(org.apache.geronimo.kernel.config.ConfigurationManagerTest) testRestartException(org.apache.geronimo.kernel.config.ConfigurationManagerTest) The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn reassigned GERONIMO-4369: -- Assignee: Joe Bohn The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4405) Postgresql new drives would not be listed in Drive Jars list and download driver list
[ https://issues.apache.org/jira/browse/GERONIMO-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646926#action_12646926 ] Lin Sun commented on GERONIMO-4405: --- For No. 3, we cannot do anything about it, before the postgresql 8.3 is published at a public repo. I think i recently added 8.2 there. For No. 2, you might want to check if the list is cached (could be done on purpose). For example, does this work if you logout admin console or/and exit your browser? Postgresql new drives would not be listed in Drive Jars list and download driver list - Key: GERONIMO-4405 URL: https://issues.apache.org/jira/browse/GERONIMO-4405 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1.3 Environment: Any platform Reporter: viola.lu Priority: Minor Attachments: GERONIMO-4405.patch Steps: 1.login admin console, go to repository porlet, install a postgresql jdbc driver 8.3 2.Go to database pool porlet-create a datasource type postgresql local or XA, click next.Newly installed driver is not listed in driver jars. 3.CLick download driver button, just postgresql 8.1.8.2,7.4 is listed, can't choose 8.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4349) jdbc driver is installed to wrong repository after installed server specific repo plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646925#action_12646925 ] Ted Kirby commented on GERONIMO-4349: - That sounds right, Joe. We've seen this before: ordering differences with different JDKs causing problems. Forrest, I'd suggest DEBUG tracing of runs with both Sun and IBM JDKs, and compare the logs to see where things go bad with the IBM JDK. It looks like it's somewhere around the code where install directory is chosen. I'm not familiar with that part of the code. If you need more help, let me/us know. Ted Kirby jdbc driver is installed to wrong repository after installed server specific repo plugin Key: GERONIMO-4349 URL: https://issues.apache.org/jira/browse/GERONIMO-4349 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.3 Reporter: Forrest Xia Priority: Minor 1. start default server instance 2. install server specific repo plugin at http://geronimo.apache.org/plugins/geronimo-2.1.3/ 3. create a database pool with wizard, click download driver to install postgresql jdbc driver 4. after downloaded and installed, check where it is stored Issue: it is installed into GERONIMO_HOME/var/repository. But I think it should be installed into GERONIMO_HOME/repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4405) Postgresql new drives would not be listed in Drive Jars list and download driver list
[ https://issues.apache.org/jira/browse/GERONIMO-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646928#action_12646928 ] Lin Sun commented on GERONIMO-4405: --- Just saw the patch. You might want to check why the versions are listed explicitly before and whether you should just add 8.3 to the list (instead of eliminate the version). This could be a way to control the jdbc jars that we tested. Postgresql new drives would not be listed in Drive Jars list and download driver list - Key: GERONIMO-4405 URL: https://issues.apache.org/jira/browse/GERONIMO-4405 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1.3 Environment: Any platform Reporter: viola.lu Priority: Minor Attachments: GERONIMO-4405.patch Steps: 1.login admin console, go to repository porlet, install a postgresql jdbc driver 8.3 2.Go to database pool porlet-create a datasource type postgresql local or XA, click next.Newly installed driver is not listed in driver jars. 3.CLick download driver button, just postgresql 8.1.8.2,7.4 is listed, can't choose 8.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646934#action_12646934 ] Joe Bohn commented on GERONIMO-4369: It seems that the test specifically verifies that during a restart the configuration is only stopped and started, not unloaded, loaded, or failed. So, perhaps rather than attempting to force unload/reload into the restart we need to look at adding the capability to reload the configuration? The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GEP build failure
Thanks Joe Joe Bohn wrote: Hmm ... it doesn't look like the snapshots were published yet, so I'll start to push them out later tonight or tomorrow morning. I'm in the middle of publishing the 2.1.4-SNAPSHOTS now. Joe Tim McConnell wrote: Thanks Donald, that would certainly help Donald Woods wrote: Do we need to publish an updated 2.2-SNAPSHOT server build to the Apache repo to resolve this? -Donald Tim McConnell wrote: Hi Ashish, you just need to build the trunk version of the server and it will create the artifact that you're missing. Ashish Jain wrote: Hi, I get the following error while building GEP [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Unable to get dependency information: Unable to read the metadata file for artif act 'org.apache.geronimo.configs:dojo-legacy-tomcat:car': Cannot find parent: or g.apache.geronimo.plugins:dojo-legacy for project: org.apache.geronimo.configs:d ojo-legacy-tomcat:car:null for project org.apache.geronimo.configs:dojo-legacy-t omcat:car:null org.apache.geronimo.configs:dojo-legacy-tomcat:car:2.2-SNAPSHOT from the specified remote repositories: apache.incubator (http://people.apache.org/repo/m2-incubating-repository/), central (http://repo1.maven.org/maven2), snapshots.openqa.org http://snapshots.openqa.org (http://archiva.openqa.org/repository/snapshots), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), java.net http://java.net (http://download.java.net/maven/1/), releases.openqa.org http://releases.openqa.org (http://archiva.openqa.org/repository/releases), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Path to dependency: 1) org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 2) org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-S NAPSHOT 3) org.apache.geronimo.plugingroups:javaee5-tomcat:car:2.2-SNAPSHOT 4) org.apache.geronimo.plugingroups:console-tomcat:car:2.2-SNAPSHOT 5) org.apache.geronimo.plugins:mconsole-tomcat:car:2.2-SNAPSHOT [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 9 minutes 7 seconds [INFO] Finished at: Mon Nov 03 18:01:27 IST 2008 [INFO] Final Memory: 105M/431M [INFO] Any ideas?? Thanks Ashish -- Thanks, Tim McConnell
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646942#action_12646942 ] Joe Bohn commented on GERONIMO-4369: It also looks like this is related to http://issues.apache.org/jira/browse/GERONIMO-3269 The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-530) Faile to show EJB Security Role in security UI
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed reassigned GERONIMODEVTOOLS-530: -- Assignee: B.J. Reed (was: Tim McConnell) Faile to show EJB Security Role in security UI -- Key: GERONIMODEVTOOLS-530 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-530 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3 Environment: OS:Windows 2003 and Suse10 Reporter: viola.lu Assignee: B.J. Reed Steps: 1.Create an EJB project,edit its ejb-jar.xml, append snippnet below: assembly-descriptor security-rolerole-namecontent-admin/role-name/security-role /assembly-descriptor 2.Open openejb-jar.xml, click Security tab in deployment descriptor, but in security role, no content display.Different from web dynamic application and Enterpise Project's Behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3316) warn but don't prevent deployment if an ear's manifest cps are messed up, and provide more info on where.
[ https://issues.apache.org/jira/browse/GERONIMO-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn resolved GERONIMO-3316. Resolution: Fixed warn but don't prevent deployment if an ear's manifest cps are messed up, and provide more info on where. - Key: GERONIMO-3316 URL: https://issues.apache.org/jira/browse/GERONIMO-3316 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M6, 2.0-M7, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2 Reporter: David Jencks Assignee: Joe Bohn Fix For: 2.1.4, 2.2 DeploymentContext.getCompleteManifestClassPath figures out the whole set of jars in an ear in a modules classpath. If somethings missing it throws an exception and prevents deployment. We need a switch to be more lenient, and we need to provide more info when there's a problem on which jar has the problem and how we found it. Thanks to David Harbige on the user list for pointing out that this is a big usability problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4349) jdbc driver is installed to wrong repository after installed server specific repo plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646898#action_12646898 ] Joe Bohn commented on GERONIMO-4349: Forrest, Thanks for the additional information ... that is certainly interesting. It also doesn't happen with the Mac JDK (my test). So it looks like this has to do with jdk implementation differences ... perhaps the use of an indeterminate set when an ordered list is necessary to return an expected target. jdbc driver is installed to wrong repository after installed server specific repo plugin Key: GERONIMO-4349 URL: https://issues.apache.org/jira/browse/GERONIMO-4349 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.3 Reporter: Forrest Xia Priority: Minor 1. start default server instance 2. install server specific repo plugin at http://geronimo.apache.org/plugins/geronimo-2.1.3/ 3. create a database pool with wizard, click download driver to install postgresql jdbc driver 4. after downloaded and installed, check where it is stored Issue: it is installed into GERONIMO_HOME/var/repository. But I think it should be installed into GERONIMO_HOME/repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 2.2 (trunk) bucket-o-snapshots
Gianny Damour wrote: On 12/11/2008, at 10:04 AM, Joe Bohn wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid-December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? I will release WADI 2.1 whenever a release version is required for Geronimo. Thanks Gianny. Is there any reason to avoid pursuing a release now? Are you anticipating more changes from Geronimo or other projects soon? Any snapshot dependencies that we can quickly remove will help us more keenly focus on those that require a bit more effort. Thanks, Joe
[jira] Commented: (GERONIMODEVTOOLS-530) Faile to show EJB Security Role in security UI
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646939#action_12646939 ] B.J. Reed commented on GERONIMODEVTOOLS-530: When the security role code was added to the GUI, it looks like the author of the code realized that the EJB stuff couldn't be done the same way as the other security role codes. I think they ran out of time before being able to complete this. It looks like we should be able to update EjbJavaEEDeploymnetDescriptor.getSecurityRoles () and EjbJ2EEDeploymnetDescriptor.getSecurityRoles () to perform an equivalent function. Not sure if it was intentional or not, but the effect is that this will be deferred to a release after 2.1.3. Will provide more details when I have a little more time to look at this. Faile to show EJB Security Role in security UI -- Key: GERONIMODEVTOOLS-530 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-530 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3 Environment: OS:Windows 2003 and Suse10 Reporter: viola.lu Assignee: B.J. Reed Steps: 1.Create an EJB project,edit its ejb-jar.xml, append snippnet below: assembly-descriptor security-rolerole-namecontent-admin/role-name/security-role /assembly-descriptor 2.Open openejb-jar.xml, click Security tab in deployment descriptor, but in security role, no content display.Different from web dynamic application and Enterpise Project's Behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Dynamically adding ModuleBuilderExtensions and NamingBuilders
As part of deploying SCA enhanced Web Applications in Geronimo with Tuscany Plugin, I am looking to add a ModuleBuilderExtension (MBE) to TomcatModuleBuilder and a NamingBuilder. The purpose of the MBE is to add SCA related EmbeddedRuntimeGBean to the web application config which will deploy the application composite to the SCA domain. The purpose of the NamingBuilder is to add SCA Domain and other objects (required for injection of SCA references in servlets etc.) into the WebAppContext. I am seeing that the MBE and NamingBuilder GBeans which are added as part of the Tuscany Plugin can not get dynamically added to the MBEs configured in tomcat6-builder config and NamingBuilders configured in j2ee-deployer config. The one option I see is to update the plan.xml files in tomcat6-builder and j2ee-deployer configs and rebuild the server. But this won't be like the MBE and NamingBuilder is getting added as part of Tuscany-plugin installation. The other option is to add (don't know if it is easy to do this hack) the MBE and NamingBuilder to the corresponding collections in TomcatModuleBuilder and NamingBuilder GBeans. I appreciate any suggestions/comments or inputs on any alternate approach that I am not seeing. Thanks, Vamsi
Re: [Heads up] SSH server in java
I've just done a real quick prototype to plug into smx kernel and I've
been able to log in into smx kernel using an ssh client and issue a
few commands.
Following is the class that does everything and the spring config to
start the ssh server.
The BogusPasswordAuthenticator is a dummy class which I pasted below too.
Notice the use of stream filters to convert CR / CRLF stuff. I think
this is because both sshd and the geronimo gshell do not handle well
the pty request and/or VT100 stuff. But I'm still not sure where the
conversion should happen exactly.
Also note that i've redefined the ConsoleErrorHandlerImpl, because the
default one uses the application.getIO() for displaying errors so they
are not available remotely.
Let me know what you think, but it basically makes the whole remote
bits of gshell unused.
I have not implemented the ssh command which should be easy using jsch lib.
Let me know if / how I can help you with that bits.
==
package org.apache.servicemix.kernel.gshell.core.sshd;
import com.google.code.sshd.PasswordAuthenticator;
public class BogusPasswordAuthenticator implements PasswordAuthenticator {
public Object authenticate(String username, String password) {
return (username != null username.equals(password)) ?
username : null;
}
}
==
bean name=sshServer class=com.google.code.sshd.SshServer
init-method=start destroy-method=stop
property name=port value=8000 /
property name=shellFactory
bean
class=org.apache.servicemix.kernel.gshell.core.sshd.GShellShellFactory
property name=branding ref=branding /
property name=completers
list
ref bean=commandsCompleter/
ref bean=aliasNameCompleter/
/list
/property
property name=executor ref=commandLineExecutor /
property name=history
bean
class=org.apache.geronimo.gshell.wisdom.shell.HistoryImpl
constructor-arg ref=application/
/bean
/property
property name=prompter
bean
class=org.apache.geronimo.gshell.wisdom.shell.ConsolePrompterImpl
constructor-arg ref=application/
/bean
/property
/bean
/property
property name=hostKeyProvider
bean class=com.google.code.sshd.hostkeys.FileHostKeyProvider
constructor-arg
list
value${hostKey}/value
/list
/constructor-arg
/bean
/property
property name=passwordAuthenticator
!-- TODO: provide real authentication --
bean
class=org.apache.servicemix.kernel.gshell.core.sshd.BogusPasswordAuthenticator
/
/property
!-- Do not use public keys for now
property name=publickeyAuthenticator
bean class=com.google.code.sshd.BogusPublickeyAuthenticator /
/property
--
!-- Standard properties --
property name=channelFactories
list
bean
class=com.google.code.sshd.channel.ChannelSession$Factory /
/list
/property
property name=cipherFactories
list
bean class=com.google.code.sshd.cipher.AES128CBC$Factory /
bean
class=com.google.code.sshd.cipher.TripleDESCBC$Factory /
bean class=com.google.code.sshd.cipher.BlowfishCBC$Factory /
bean class=com.google.code.sshd.cipher.AES192CBC$Factory /
bean class=com.google.code.sshd.cipher.AES256CBC$Factory /
/list
/property
property name=compressionFactories
list
bean
class=com.google.code.sshd.compression.CompressionNone$Factory /
/list
/property
property name=keyExchangeFactories
list
bean class=com.google.code.sshd.kex.DHG1$Factory /
/list
/property
property name=macFactories
list
bean class=com.google.code.sshd.mac.HMACMD5$Factory /
bean class=com.google.code.sshd.mac.HMACSHA1$Factory /
bean class=com.google.code.sshd.mac.HMACMD596$Factory /
bean class=com.google.code.sshd.mac.HMACSHA196$Factory /
/list
/property
property name=randomFactory
bean class=com.google.code.sshd.random.JceRandom$Factory /
/property
property name=userAuthFactories
list
bean
class=com.google.code.sshd.auth.UserAuthPublicKey$Factory /
bean
class=com.google.code.sshd.auth.UserAuthPassword$Factory /
/list
/property
Re: Dynamically adding ModuleBuilderExtensions and NamingBuilders
On Nov 12, 2008, at 1:07 PM, Vamsavardhana Reddy wrote: As part of deploying SCA enhanced Web Applications in Geronimo with Tuscany Plugin, I am looking to add a ModuleBuilderExtension (MBE) to TomcatModuleBuilder and a NamingBuilder. The purpose of the MBE is to add SCA related EmbeddedRuntimeGBean to the web application config which will deploy the application composite to the SCA domain. The purpose of the NamingBuilder is to add SCA Domain and other objects (required for injection of SCA references in servlets etc.) into the WebAppContext. I am seeing that the MBE and NamingBuilder GBeans which are added as part of the Tuscany Plugin can not get dynamically added to the MBEs configured in tomcat6- builder config and NamingBuilders configured in j2ee-deployer config. The one option I see is to update the plan.xml files in tomcat6-builder and j2ee-deployer configs and rebuild the server. But this won't be like the MBE and NamingBuilder is getting added as part of Tuscany-plugin installation. The other option is to add (don't know if it is easy to do this hack) the MBE and NamingBuilder to the corresponding collections in TomcatModuleBuilder and NamingBuilder GBeans. I appreciate any suggestions/comments or inputs on any alternate approach that I am not seeing. Yup, this is a problem. So far we've sidestepped it by just adding all the known desired MBE's to the appropriate *-deployer plan, and as you have found this is non-extensible. One possiblitly would be to define marker interfaces such as WebMBE, EjbMBE, etc that the appropriate MBE's could implement and use the interface in the references pattern. Anyone have a better idea? thanks david jencks Thanks, Vamsi
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12647155#action_12647155 ] Ivan commented on GERONIMO-4369: Thanks, Joe, I should run the testcase first, I just verified that whether the issue is fixed. From my side, the restart action is a more user-oriented action, it should use the newest configuration. A reload action is a good suggestion, but I am not sure that it is feasible to update the configuration gbean while it is in the running state. I wonder why we should not unload/load the configurations, is there a story about it ? Thanks again ! The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4407) Dupldate attribute entries exist in the config.xml while changing the value between zero-length string and no-zero-length string
Dupldate attribute entries exist in the config.xml while changing the value between zero-length string and no-zero-length string Key: GERONIMO-4407 URL: https://issues.apache.org/jira/browse/GERONIMO-4407 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3, 2.2 Environment: Windows XP JDK 1.5.0 Reporter: Ivan While an attribute's initial value is no-zero length value, then we set its value with zero-length value in the portlet, then we could find the in the config.xml file, there are duplicate attribute entries. Like ... attribute name=LoginTimeout0/attribute attribute name=ShutdownDatabaseshutdown2/attribute attribute name=ShutdownDatabase/ .. It seems that it is caused we use two Map (attributes, clearAttributes ) to keep the attribute values, while we setting the attribute, no code checks that the attribute should only exist in one map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12647177#action_12647177 ] Joe Bohn commented on GERONIMO-4369: I don't know the full rationale, but I know that it has always been a goal to keep the concepts of load/unload and start/stop independent. It certainly provides for more flexibility. I'm starting to wonder if the problem is really in the portlet itself.There are several attributes that are similar between generic and non-generic pools. User name falls into that category. Perhaps we're not updating the name in some local config structure and it is only update when reloaded. This is unrelated but I also noticed something strange with user name when creating an embedded derby (non-xa) pool. For some reason we get another attribute called Shutdown Database which seems to be getting confused with User Name since the value for Shutdown Database is by default the user name and the value for User Name is null. The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12647187#action_12647187 ] Ivan commented on GERONIMO-4369: Thanks, Joe, it does let me know more about how the kernel works. I found we could use reload instead of the restart in the port let while user try to restart the j2ee connector. I am running some console testcases, then upload the patch. Thanks ! The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-534) Fail to remove directory from repository after removing project from elicpse
Fail to remove directory from repository after removing project from elicpse Key: GERONIMODEVTOOLS-534 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3 Environment: OS:windows 2003 Reporter: viola.lu Assignee: Tim McConnell Priority: Minor Steps: 1.Create an ejb project in elicpse, and deploy it to geronimo server via WEP, some errors output in console 2.So i remove it from current server runtime.Do some modifcation, and redeploy it 3.But it tells me that 11:39:19,546 ERROR [RepositoryConfigurationStore] C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is not an empty directory 11:42:13,765 ERROR [RepositoryConfigurationStore] C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is not an empty directory 4.I should go to repository to remove default directory first and go on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-534) Fail to remove directory from repository after removing project from elicpse
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMODEVTOOLS-534: -- Attachment: testejb.jar Fail to remove directory from repository after removing project from elicpse Key: GERONIMODEVTOOLS-534 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-534 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3 Environment: OS:windows 2003 Reporter: viola.lu Assignee: Tim McConnell Priority: Minor Attachments: testejb.jar Steps: 1.Create an ejb project in elicpse, and deploy it to geronimo server via WEP, some errors output in console 2.So i remove it from current server runtime.Do some modifcation, and redeploy it 3.But it tells me that 11:39:19,546 ERROR [RepositoryConfigurationStore] C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is not an empty directory 11:42:13,765 ERROR [RepositoryConfigurationStore] C:\geronimo-tomcat6-javaee5-2.1.3\repository\default\test\1.0\test-1.0.car is not an empty directory 4.I should go to repository to remove default directory first and go on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4369: --- Attachment: (was: Geronimo-4369.patch) The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369-11.13.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4369: --- Component/s: (was: kernel) console Update the components, it is belong to console category. The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369-11.13.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated GERONIMO-4369: --- Attachment: Geronimo-4369-11.13.patch Let's do the restart action step by step, first stop it, then start it, do not use any shortcut method in the configuration manager. So that it will be same behavior with GERONIMO-3269. Please help to review the patch, thanks ! The new attribute values are overwrote while restarting the DB pool connector - Key: GERONIMO-4369 URL: https://issues.apache.org/jira/browse/GERONIMO-4369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Environment: Geronimo 2.2 snapshot JDK 1.5 Windows XP Reporter: Ivan Assignee: Joe Bohn Fix For: 2.2 Attachments: Geronimo-4369-11.13.patch After editing the values in the db pool, then restart it in the console, the new values lost. When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect, Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
