[BUILD] trunk: Failed for Revision: 755126
Geronimo Revision: 755126 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090317/build-0300.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090317/unit-test-reports for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/), ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT 2) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/), ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT 2) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/), ibiblio.org
Re: [DISCUSSION] to create a set of maven archetypes for applications running on geronimo ?
From my point of view, every current geronimo sample could be converted to a archetype. So that the user just needs install maven and he could just type a command like this: mvn archetype:generate -DarcheTypeCatalog= http://geronimo.apache.org/archetypes/samples he will get a sample menu like this: Choose archetype: 1: internal - hello (geronimo sample web application project) 2: internal - calculator-stateless-pojo (geronimo sample ejb project) 3: internal - mdb (geronimo Message-Driven Bean sample project) 4: internal - GBean(simple geronimo GBean project) 5: internal - 6: internal - 7: internal - Choose a number: (1/2/3/4/5/6/7) 1: : 1 select 1 to create a hello sample project will bring him to a wizard like this: Define value for geronimo_version: : 2.1.4 Define value for context_root: : hellocontext Define value for groupId: : my.first.geronimo.web Define value for artifactId: : helloApp Define value for version: 1.0-SNAPSHOT: : Define value for package: my.first.geronimo.web: : Confirm properties configuration: geronimo_version: 2.1.4 context_root: hellocontext groupId: my.first.geronimo.web artifactId: helloApp version: 1.0-SNAPSHOT package: my.first.geronimo.web Y: : Y notice the user could define which geronimo version he is using and defind the context root when generating the application. The two values will be used to generate a geronimo-web.xml like this: web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:sec=http://geronimo.apache.org/xml/ns/security-2.0; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.2; sys:environment sys:moduleId sys:groupIdmy.first.geronimo.web/sys:groupId sys:artifactIdhelloApp/sys:artifactId sys:version1.0-SNAPSHOT/sys:version sys:typecar/sys:type /sys:moduleId sys:dependencies !--some dependency on geronimo 2.1.4 here /sys:dependencies sys:hidden-classes/ sys:non-overridable-classes/ /sys:environment context-root/hellocontext/context-root /web-app I can see following benefits by creating these kind of sample archetypes: 1, User does not need to install a subversion to get the samples or to download the samples zip. He just need to install a maven to get all kinds of samples whatever he wants. 2, geronimo version could be provided at sample project generating time. As I know, most of samples content does not change at all except those geronimo version update. To keep these stable samples to archetypes can save the time to maintain every samples per geronimo release. (of course, for those unstable samples, we still need to update them per geronimo release) 3, Other key properties in geronimo deployment plan could be provided at sample project generating time. This is helpful for user to understand the essential elements of geronimio deployment plan. Current maven archetype is using velocity template which is very powerful to generate project contents based on user's input. On Tue, Mar 17, 2009 at 1:41 AM, David Jencks david_jen...@yahoo.comwrote: On Mar 16, 2009, at 12:18 AM, Shawn Jiang wrote: Maven archetype is a powerful tools to make life easier when developers want to create a project from scratch. Currently, Geronimo is using archetype to create new testsuite/assembly/plugin/ quickly. 1: local - geronimo-archetype-testsuite (testsuite) 2: local - geronimo-assembly-archetype (geronimo-assembly-archetype) 3: local - geronimo-plugin-archetype (geronimo-plugin-archetype) 4: local - xmlbeans-maven-plugin (xmlbeans-maven-plugin) Which can only help geronimo developers/contributors when they want to create their new testsuite/assembly/plugin. There's no archetype for geronimo users who want to create their geronimo Apps/Assets easily from scratch. I'm wondering if geronimo could provide a set of new archetypes for Apps/assets running in geronimo. Some initial candidates are: 1, war-geronimo-archetype A simple war which contains the geronimo deployment plan. 2, ear-geronimo-archtype A maven project that contains 4 modules: 1, a war module 2, a ear module 3, a ejb module 4, a client module. 3, datasource-geronimo-archtypes There should be many sub archtypes to create different datasources plan. 4, security-geronimo-archtypes There should be many sub archtypes to create different(properties/db/ldap) realms. 5, GBean-geronimo-archtype A simple GBean development archtype with two mode: normal/annotation Any comments ? I don't quite understand yet what these archetypes would provide. The most plausible thing would be to add a fill in the blanks plan template. I'm not sure an archetype is the best way to do this, but I'm certainly open to seeing how it works. Our existing plugin and assembly archetypes are rather obsolete and don't use the current archetype infrastructure. I wonder if a more practical
Re: [DISCUSSION] to create a set of maven archetypes for applications running on geronimo ?
On Mar 16, 2009, at 11:50 PM, Shawn Jiang wrote: From my point of view, every current geronimo sample could be converted to a archetype. So that the user just needs install maven and he could just type a command like this: mvn archetype:generate -DarcheTypeCatalog=http://geronimo.apache.org/archetypes/samples he will get a sample menu like this: Choose archetype: 1: internal - hello (geronimo sample web application project) 2: internal - calculator-stateless-pojo (geronimo sample ejb project) 3: internal - mdb (geronimo Message-Driven Bean sample project) 4: internal - GBean(simple geronimo GBean project) 5: internal - 6: internal - 7: internal - Choose a number: (1/2/3/4/5/6/7) 1: : 1 select 1 to create a hello sample project will bring him to a wizard like this: Define value for geronimo_version: : 2.1.4 Define value for context_root: : hellocontext Define value for groupId: : my.first.geronimo.web Define value for artifactId: : helloApp Define value for version: 1.0-SNAPSHOT: : Define value for package: my.first.geronimo.web: : Confirm properties configuration: geronimo_version: 2.1.4 context_root: hellocontext groupId: my.first.geronimo.web artifactId: helloApp version: 1.0-SNAPSHOT package: my.first.geronimo.web Y: : Y notice the user could define which geronimo version he is using and defind the context root when generating the application. The two values will be used to generate a geronimo-web.xml like this: web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:sec=http://geronimo.apache.org/xml/ns/security-2.0; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.2; sys:environment sys:moduleId sys:groupIdmy.first.geronimo.web/sys:groupId sys:artifactIdhelloApp/sys:artifactId sys:version1.0-SNAPSHOT/sys:version sys:typecar/sys:type /sys:moduleId sys:dependencies !--some dependency on geronimo 2.1.4 here /sys:dependencies sys:hidden-classes/ sys:non-overridable-classes/ /sys:environment context-root/hellocontext/context-root /web-app I can see following benefits by creating these kind of sample archetypes: 1, User does not need to install a subversion to get the samples or to download the samples zip. He just need to install a maven to get all kinds of samples whatever he wants. 2, geronimo version could be provided at sample project generating time. As I know, most of samples content does not change at all except those geronimo version update. To keep these stable samples to archetypes can save the time to maintain every samples per geronimo release. (of course, for those unstable samples, we still need to update them per geronimo release) 3, Other key properties in geronimo deployment plan could be provided at sample project generating time. This is helpful for user to understand the essential elements of geronimio deployment plan. Current maven archetype is using velocity template which is very powerful to generate project contents based on user's input. It looks to me as if there are no plans in the javaee apps parts of the samples apps, so the plans are all in the plugin modules. I really don't think we want to duplicate the functionality of the existing archetypes that do a fine job of creating projects for java ee apps. If you really do want to help people make projects like the sample apps, the way to do that is to improve the plugin archetype. I like your ideas about what can be generated in the geronimo plan. I think we can also generate a lot more of the pom than we do now. I would be very tempted to try stringtemplate instead of velocity. I think its clear MVC separation and roots in code generation technology (it's the output stage for antlr) may prove useful for the manipulation we need to do. While enabling people to reproduce our sample apps is probably better than what we do now, I'd prefer to help them with apps that actually do a realistic amount of work. I think improving the plugin archetype would be a really big help. thanks david jencks On Tue, Mar 17, 2009 at 1:41 AM, David Jencks david_jen...@yahoo.com wrote: On Mar 16, 2009, at 12:18 AM, Shawn Jiang wrote: Maven archetype is a powerful tools to make life easier when developers want to create a project from scratch. Currently, Geronimo is using archetype to create new testsuite/assembly/ plugin/ quickly. 1: local - geronimo-archetype-testsuite (testsuite) 2: local - geronimo-assembly-archetype (geronimo-assembly-archetype) 3: local - geronimo-plugin-archetype (geronimo-plugin-archetype) 4: local - xmlbeans-maven-plugin (xmlbeans-maven-plugin) Which can only help geronimo developers/contributors when they want to create their new testsuite/assembly/plugin. There's no archetype for geronimo users who want to create
[jira] Created: (GERONIMO-4589) Does not echo the command after expection occur in command line deploy.sh
Does not echo the command after expection occur in command line deploy.sh - Key: GERONIMO-4589 URL: https://issues.apache.org/jira/browse/GERONIMO-4589 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 2.1.4 Environment: This problem is reproduced on following platforms: - Redhat 5.2 - AIX 6.1 - Susu Linux Enterprise Server 10 - Ubuntu 8 Reporter: Han Hong Fang Steps to reproduce this problem: 1. start Geronimo server 2. deploy a sample web app from command line using: ./deploy.sh deploy $sample_home/cviewer-2.1.1.2.war, and it can be installed and started successfully, and its module id is com.ibm.wasce.samples/cviewer/2.1.1.2/car; 3. Try to stop the module from command line with wrong module id: ./deploy.sh stop com.ibm.wasce.samples/cviewer, then the following exception occurs Using GERONIMO_HOME: /home/jeff/IBM/Framework-1.0_online_J2EE_deployer Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/opt/ibm/java-i386-60/jre Exception in thread main java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : com.ibm.wasce.samples/cviewer/2.1.1.2 at java.lang.Throwable.init(Throwable.java:67) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:59) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:193) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:57) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) The problem is after this exception, the terminal will no echo any command you type. e.g,. if you type ls, you can not see ls being ehcoed in terminal, but if you click enter, you can see the command still works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSSION] to create a set of maven archetypes for applications running on geronimo ?
It looks to me as if there are no plans in the javaee apps parts of the samples apps, so the plans are all in the plugin modules. I really don't think we want to duplicate the functionality of the existing archetypes that do a fine job of creating projects for java ee apps. If you really do want to help people make projects like the sample apps, the way to do that is to improve the plugin archetype. Thanks for your comments. actually, what I said was to make the pom.xml and plan.xml template but not the JEE app itself. For example: servlet-examples/ pom.xml servlet-examples-jetty/ pom.xml src/ main/ plan/ plan.xml servlet-examples-tomcat/ servlet-examples-war/ From this pespective, what I was talking about is to create plugins archetype instead of JEE app archetype. I like your ideas about what can be generated in the geronimo plan. I think we can also generate a lot more of the pom than we do now. I agree. I would be very tempted to try stringtemplate instead of velocity. I think its clear MVC separation and roots in code generation technology (it's the output stage for antlr) may prove useful for the manipulation we need to do. But how could we reuse the existing powerful maven archetype if using stringtemplate ? I feel that StringTemplate is more useful in a MVC framework but not in a project generating tool. Do you agree ? While enabling people to reproduce our sample apps is probably better than what we do now, I'd prefer to help them with apps that actually do a realistic amount of work. I think improving the plugin archetype would be a really big help. I suggest to start with the current sample plugins. The final goal is to reduce most of the effort to release all samples for each geronimo version by providing stable archetype. thanks david jencks On Tue, Mar 17, 2009 at 3:35 PM, David Jencks david_jen...@yahoo.comwrote: On Mar 16, 2009, at 11:50 PM, Shawn Jiang wrote: From my point of view, every current geronimo sample could be converted to a archetype. So that the user just needs install maven and he could just type a command like this: mvn archetype:generate -DarcheTypeCatalog= http://geronimo.apache.org/archetypes/samples he will get a sample menu like this: Choose archetype: 1: internal - hello (geronimo sample web application project) 2: internal - calculator-stateless-pojo (geronimo sample ejb project) 3: internal - mdb (geronimo Message-Driven Bean sample project) 4: internal - GBean(simple geronimo GBean project) 5: internal - 6: internal - 7: internal - Choose a number: (1/2/3/4/5/6/7) 1: : 1 select 1 to create a hello sample project will bring him to a wizard like this: Define value for geronimo_version: : 2.1.4 Define value for context_root: : hellocontext Define value for groupId: : my.first.geronimo.web Define value for artifactId: : helloApp Define value for version: 1.0-SNAPSHOT: : Define value for package: my.first.geronimo.web: : Confirm properties configuration: geronimo_version: 2.1.4 context_root: hellocontext groupId: my.first.geronimo.web artifactId: helloApp version: 1.0-SNAPSHOT package: my.first.geronimo.web Y: : Y notice the user could define which geronimo version he is using and defind the context root when generating the application. The two values will be used to generate a geronimo-web.xml like this: web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.2; xmlns:sec=http://geronimo.apache.org/xml/ns/security-2.0; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.2; sys:environment sys:moduleId sys:groupIdmy.first.geronimo.web/sys:groupId sys:artifactIdhelloApp/sys:artifactId sys:version1.0-SNAPSHOT/sys:version sys:typecar/sys:type /sys:moduleId sys:dependencies !--some dependency on geronimo 2.1.4 here /sys:dependencies sys:hidden-classes/ sys:non-overridable-classes/ /sys:environment context-root/hellocontext/context-root /web-app I can see following benefits by creating these kind of sample archetypes: 1, User does not need to install a subversion to get the samples or to download the samples zip. He just need to install a maven to get all kinds of samples whatever he wants. 2, geronimo version could be provided at sample project generating time. As I know, most of samples content does not change at all except those geronimo version update. To keep these stable samples to archetypes can save the time to maintain every samples per geronimo release. (of course, for those unstable samples, we still need to update them per geronimo release) 3, Other key properties in geronimo deployment plan could be provided at sample project generating time. This is helpful for user to understand the essential elements of geronimio deployment plan. Current maven archetype is using
[jira] Assigned: (GERONIMO-4589) Does not echo the command after expection occur in command line deploy.sh
[ https://issues.apache.org/jira/browse/GERONIMO-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Han Hong Fang reassigned GERONIMO-4589: --- Assignee: Han Hong Fang Does not echo the command after expection occur in command line deploy.sh - Key: GERONIMO-4589 URL: https://issues.apache.org/jira/browse/GERONIMO-4589 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Environment: This problem is reproduced on following platforms: - Redhat 5.2 - AIX 6.1 - Susu Linux Enterprise Server 10 - Ubuntu 8 Reporter: Han Hong Fang Assignee: Han Hong Fang Steps to reproduce this problem: 1. start Geronimo server 2. deploy a sample web app from command line using: ./deploy.sh deploy $sample_home/cviewer-2.1.1.2.war, and it can be installed and started successfully, and its module id is com.ibm.wasce.samples/cviewer/2.1.1.2/car; 3. Try to stop the module from command line with wrong module id: ./deploy.sh stop com.ibm.wasce.samples/cviewer, then the following exception occurs Using GERONIMO_HOME: /home/jeff/IBM/Framework-1.0_online_J2EE_deployer Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/opt/ibm/java-i386-60/jre Exception in thread main java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : com.ibm.wasce.samples/cviewer/2.1.1.2 at java.lang.Throwable.init(Throwable.java:67) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:59) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:193) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:57) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) The problem is after this exception, the terminal will no echo any command you type. e.g,. if you type ls, you can not see ls being ehcoed in terminal, but if you click enter, you can see the command still works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4589) Does not echo the command after expection occur in command line deploy.sh
[ https://issues.apache.org/jira/browse/GERONIMO-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Han Hong Fang updated GERONIMO-4589: Attachment: GERONIMO-4589.patch Hi, I attach the patch for this problem, could somebody help to review it? Thanks! Does not echo the command after expection occur in command line deploy.sh - Key: GERONIMO-4589 URL: https://issues.apache.org/jira/browse/GERONIMO-4589 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Environment: This problem is reproduced on following platforms: - Redhat 5.2 - AIX 6.1 - Susu Linux Enterprise Server 10 - Ubuntu 8 Reporter: Han Hong Fang Assignee: Han Hong Fang Attachments: GERONIMO-4589.patch Steps to reproduce this problem: 1. start Geronimo server 2. deploy a sample web app from command line using: ./deploy.sh deploy $sample_home/cviewer-2.1.1.2.war, and it can be installed and started successfully, and its module id is com.ibm.wasce.samples/cviewer/2.1.1.2/car; 3. Try to stop the module from command line with wrong module id: ./deploy.sh stop com.ibm.wasce.samples/cviewer, then the following exception occurs Using GERONIMO_HOME: /home/jeff/IBM/Framework-1.0_online_J2EE_deployer Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/opt/ibm/java-i386-60/jre Exception in thread main java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : com.ibm.wasce.samples/cviewer/2.1.1.2 at java.lang.Throwable.init(Throwable.java:67) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:59) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:193) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:57) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) The problem is after this exception, the terminal will no echo any command you type. e.g,. if you type ls, you can not see ls being ehcoed in terminal, but if you click enter, you can see the command still works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4589) Does not echo the command after expection occur in command line deploy.sh
[ https://issues.apache.org/jira/browse/GERONIMO-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682596#action_12682596 ] Han Hong Fang commented on GERONIMO-4589: - For the attached patch , I have tested it with followings: 1) Tested platforms: - Redhat 5.2 - AIX 6.1 - Susu Linux Enterprise Server 10 - Ubuntu 8 2) Tested scenarios: - start/stop a module with correct module ID - start/stop a module with incorrect module ID Does not echo the command after expection occur in command line deploy.sh - Key: GERONIMO-4589 URL: https://issues.apache.org/jira/browse/GERONIMO-4589 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Environment: This problem is reproduced on following platforms: - Redhat 5.2 - AIX 6.1 - Susu Linux Enterprise Server 10 - Ubuntu 8 Reporter: Han Hong Fang Assignee: Han Hong Fang Attachments: GERONIMO-4589.patch Steps to reproduce this problem: 1. start Geronimo server 2. deploy a sample web app from command line using: ./deploy.sh deploy $sample_home/cviewer-2.1.1.2.war, and it can be installed and started successfully, and its module id is com.ibm.wasce.samples/cviewer/2.1.1.2/car; 3. Try to stop the module from command line with wrong module id: ./deploy.sh stop com.ibm.wasce.samples/cviewer, then the following exception occurs Using GERONIMO_HOME: /home/jeff/IBM/Framework-1.0_online_J2EE_deployer Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/opt/ibm/java-i386-60/jre Exception in thread main java.lang.IllegalArgumentException: id must be in the form [groupId]/[artifactId]/[version]/[type] : com.ibm.wasce.samples/cviewer/2.1.1.2 at java.lang.Throwable.init(Throwable.java:67) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:59) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:193) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:57) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:164) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) The problem is after this exception, the terminal will no echo any command you type. e.g,. if you type ls, you can not see ls being ehcoed in terminal, but if you click enter, you can see the command still works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4590) One ClassLoader per Jar Model
One ClassLoader per Jar Model - Key: GERONIMO-4590 URL: https://issues.apache.org/jira/browse/GERONIMO-4590 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour As discussed on @dev, to reduce the number of ClassCastExceptions caused by collaborating configurations importing the same dependencies, the classloading design can be improved to use a shared and global poll of classloaders. Each classloader in this global poll is mapped to only one JAR. They are put in a hierarchy according to their maven dependency declarations. As maven dependencies may not be systematically correct, additional dependency declarations can also be provided by dropping a XML file artifactId-version-additional.xml beside the JAR or POM file artifactId-version.jar (.pom) whose dependencies are to be supplemented. This patch is a preview of the functionality to trigger more discussions. 22 out of the 74 configurations of the jetty-jee5 assembly can start fine with this patch. The failure observed for the failing configuration appears to be another maven dependency declaration issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4590) One ClassLoader per Jar Model
[ https://issues.apache.org/jira/browse/GERONIMO-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-4590: Attachment: additional-maven-dependencies.jar OneClassLoaderPerJar.txt OneClassLoaderPerJar.txt is a geronimo-kernel patch. additional-maven-dependencies.jar is a jar to be unpacked in the geronimo repository, which include additional maven dependency declarations for specific JAR. One ClassLoader per Jar Model - Key: GERONIMO-4590 URL: https://issues.apache.org/jira/browse/GERONIMO-4590 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.3 Reporter: Gianny Damour Assignee: Gianny Damour Attachments: additional-maven-dependencies.jar, OneClassLoaderPerJar.txt As discussed on @dev, to reduce the number of ClassCastExceptions caused by collaborating configurations importing the same dependencies, the classloading design can be improved to use a shared and global poll of classloaders. Each classloader in this global poll is mapped to only one JAR. They are put in a hierarchy according to their maven dependency declarations. As maven dependencies may not be systematically correct, additional dependency declarations can also be provided by dropping a XML file artifactId-version-additional.xml beside the JAR or POM file artifactId-version.jar (.pom) whose dependencies are to be supplemented. This patch is a preview of the functionality to trigger more discussions. 22 out of the 74 configurations of the jetty-jee5 assembly can start fine with this patch. The failure observed for the failing configuration appears to be another maven dependency declaration issue. -- 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?
On 13/03/2009, at 6:44 PM, David Jencks wrote: On Mar 12, 2009, at 10:02 AM, David Jencks wrote: On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote: On 12/03/2009, at 4:29 AM, David Jencks wrote: I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. IMO the danger here is that the maven pom may not exist or may be wrong. OSGI has the same problem in that the vast majority of released jars don't have osgi manifests. I think I saw a rumor that spring spent a lot of effort osgi-ifying a lot of commonly used jars to try to solve this problem. I also don't know if there are situations in which a small number of closely related jars need to be loaded in a single classloader, perhaps because one of the jars is optional but if present the main jar needs access to its classes. I think there was an osgi feature that looked sort of like this. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Unless you are pretty sure we won't have the kind of problems with bad community metadata suggested above it might be a good idea to do this in a sandbox branch? Thinking about this more I really expect the code will be easy compared to straightening out the dependencies :-( As a concrete example, the JACC spec needs the servlet and ejb specs but in our maven poms we've excluded them as dependencies so as to make it easier to upgrade the jars independently. While (especially with maven 3) we can probably put in the dependencies with version ranges, they aren't there now. Getting the server to work again may be time consuming. I really hope I'm wrong :-D Hi David, I just created a patch http://issues.apache.org/jira/browse/GERONIMO-4590 which provides a preview of the code changes necessary to move to a one classloader per jar model. It is not yet good enough to create a branch as only 22 configurations out of the 27 of the jetty-jee5 assemblies can successfully start (failing config is certainly a maven dependency problem). The design is rather simple: 1. when a configuraton classloader is created, configuration dependencies and classPath entries are used to generate a bunch of GlobalClassLoaders - one per dependency or one for all the classPath entries. 2. this set of GlobalClassLoaders are put in a hierarchy according to maven dependency declarations (note that dependency version declarations are not honored even if present). Maven dependency declarations can be augmented by dropping an XML file with maven like dependencies declarations. 3. the classloaders of the parent configuration of the configuration being created are added to this set of GlobalClassLoaders. 4. this set of GlobalClassLoaders is used under the hood of the configuration's MultiParentClassLoader to implement find class and resources contracts. Four maven dependency declarations had to be supplemented to start 22 configurations. Assuming the same ratio, about 14 dependency declarations may have to be supplemented to start the jetty-jee5 assembly. This is not too involving. Could you please have a cursory review of this preview patch and let me know your thoughts? Thanks, Gianny thanks david jencks thanks david jencks Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On
[BUILD] trunk: Failed for Revision: 755213
Geronimo Revision: 755213 built with tests included See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090317/build-0900.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090317/unit-test-reports for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT 2) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT 2) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http
Re: [OSGi] Support for RFC 124?
Davanum Srinivas wrote: Folks, Any interest in support for RFC 124, A Component Model for OSGi? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims I think this would be a very cool thing to support. I think first we'd have to address the issue of first providing an OSGi framework environment hosted by Geronimo. Once you've done that, RFC 124, is a natural to add on top of that. Once you have that, defined, then you can start playing with things like accessing OSGi-based services from JEE components, which would be a really powerful next step. Rick PS, in the interests of full disclosure, I should note that I'm currently working on the compliance tests suite for RFC 124, so I've had a bit of experience at seeing this in action.
Re: [OSGi] Support for RFC 124?
On Mar 17, 2009, at 8:58 AM, Davanum Srinivas wrote: Folks, Any interest in support for RFC 124, A Component Model for OSGi? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. Yes. You'll find discussion about this in the Whence the geronimo kernel? thread... --kevan
[OSGi] Support for RFC 124?
Folks, Any interest in support for RFC 124, A Component Model for OSGi? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com
Re: [OSGi] Support for RFC 124?
RFC 124 is simply a ruberstamp around what Spring-DM provides. The only real difference afaik are a few changes in the schema (mostly the namespace and replacing bean by component. This does not remove the usefulness of it btw... 2009/3/17 Davanum Srinivas dava...@gmail.com Folks, Any interest in support for RFC 124, A Component Model for OSGi? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
It has been reworked much more that just the schema changes in the standardization process. A lot of the service dynamics have changed, there have been some fairly signification changes to type conversions and property injection, a brand-new metadata API, new namespace handler support, etc. Springsource hasn't even implemented some of the new features yet, so this was far from a rubber-stamp effort. Rick Guillaume Nodet wrote: RFC 124 is simply a ruberstamp around what Spring-DM provides. The only real difference afaik are a few changes in the schema (mostly the namespace and replacing bean by component. This does not remove the usefulness of it btw... 2009/3/17 Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com Folks, Any interest in support for RFC 124, A Component Model for OSGi? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
Ok, my bad. I haven't followed closely the recent changes. The changes to the service dynamics look quite good actually. Thx for the info. 2009/3/17 Rick McGuire rick...@gmail.com It has been reworked much more that just the schema changes in the standardization process. A lot of the service dynamics have changed, there have been some fairly signification changes to type conversions and property injection, a brand-new metadata API, new namespace handler support, etc. Springsource hasn't even implemented some of the new features yet, so this was far from a rubber-stamp effort. Rick Guillaume Nodet wrote: RFC 124 is simply a ruberstamp around what Spring-DM provides. The only real difference afaik are a few changes in the schema (mostly the namespace and replacing bean by component. This does not remove the usefulness of it btw... 2009/3/17 Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com Folks, Any interest in support for RFC 124, A Component Model for OSGi? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Whence the geronimo kernel?
Rex, If you follow the discussion closely, I think David was just saying that he prefers to stay away from Require-Bundle for now, as the OSGi specification doesn't recommend people to use it, along with the probs people mentioned about it in the link I posted earlier. I also found these links interesting - http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html David, Some comments regarding #2, its essential to know what jars/bundles/plugins/modules are actually in your running system. I think OSGi framework provides the ability to display the currently running bundles, so there should be APIs to get that. For example, you type ss in equinox console to get the list of installed bundles: osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 17 RESOLVEDorg.osgi.impl.service.http_4.2.0.200902181209 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 OSGi framework also uses resolver to resolve bundles. For example, if I want to install Bundle A to the framework, and Bundle imports package AA, then when I install the bundle A, the OSGi framework uses the resolver to find out if there is any bundle that exports package AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A will be marked as INSTALLED. If you search resolver in the OSGi core spec, you'll see a couple of places that mention it. I recently took a look at the new OSGi bundle repository spec (RFC 112). It talks about the concept of Resolver and the interface Resolver It talks about scenarios where a user wants to install a bundle (that uses Import-Package), the server should be able to pull all its dependencies from the bundle repository (or repositories) on the fly using the resolver. This seems something we would need for geronimo. Lin On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang rwo...@gmail.com wrote: At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. From my point of view, I am not quite like this mix version, because we must maintain the related information in two different places, that will absolutely increase geronimo's complexity and some sorts of confusing on the dependency settings, not only to the developers but also the users. I think one of the purpose that we adopt OSGi is to make our server infrastructure standardize to the OSGi specification, but not to create a new application model. Because this may lead to a non osgi compatiable bundle, IIUC, any bundle that wanna be used in geronimo must re-write to provide the additional mvn-style information. Why do you think the require-bundle is not a workable solution for (2) ? Rex. 2009/3/14 David Jencks david_jen...@yahoo.com On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and have support for (1) (although its mostly backwards from osgi specifications) I'd say that in my (limited) experience osgi zealots typically think that (1) is essential and brush (2) under the carpet by working in constrained environments such as their eclipse workspace. I'd say that our experience with geronimo is that (1) is rarely needed if you have a working (2) (look at how many hidden-classes and non-overriable classes filters are in our poms -- none for the use of geronimo, and a few to make deploying applications that include the same jars as us work) The geronimo/maven approach to (2) is to include the dependency information with the artifact. I'm not sure what approach(es) osgi is considering -- OBR appears to
Re: Whence the geronimo kernel?
For those that are not aware of ServiceMix Kernel (I know David is), i'd like to point them to it. Feel free to download it and give it a try. It's based on felix, gshell and a few other bundles. We're using it to deploy our JBI container in ServiceMix 4 (including the geronimo transaction manager, activemq, jetty, but those are not included in the kernel). See http://servicemix.apache.org/kernel/index.html To add to this discussion, we are deploying stuff on servicemix using features, which is imho the metdata related to (2). A feature is mostly a list of OSGi bundles with some dependencies on other features and some optional configuration. We are almost using Import-Packages exclusively, using spring-dm to configure most of our services ... 2009/3/17 Lin Sun linsun@gmail.com Rex, If you follow the discussion closely, I think David was just saying that he prefers to stay away from Require-Bundle for now, as the OSGi specification doesn't recommend people to use it, along with the probs people mentioned about it in the link I posted earlier. I also found these links interesting - http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html David, Some comments regarding #2, its essential to know what jars/bundles/plugins/modules are actually in your running system. I think OSGi framework provides the ability to display the currently running bundles, so there should be APIs to get that. For example, you type ss in equinox console to get the list of installed bundles: osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 17 RESOLVEDorg.osgi.impl.service.http_4.2.0.200902181209 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 OSGi framework also uses resolver to resolve bundles. For example, if I want to install Bundle A to the framework, and Bundle imports package AA, then when I install the bundle A, the OSGi framework uses the resolver to find out if there is any bundle that exports package AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A will be marked as INSTALLED. If you search resolver in the OSGi core spec, you'll see a couple of places that mention it. I recently took a look at the new OSGi bundle repository spec (RFC 112). It talks about the concept of Resolver and the interface Resolver It talks about scenarios where a user wants to install a bundle (that uses Import-Package), the server should be able to pull all its dependencies from the bundle repository (or repositories) on the fly using the resolver. This seems something we would need for geronimo. Lin On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang rwo...@gmail.com wrote: At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. From my point of view, I am not quite like this mix version, because we must maintain the related information in two different places, that will absolutely increase geronimo's complexity and some sorts of confusing on the dependency settings, not only to the developers but also the users. I think one of the purpose that we adopt OSGi is to make our server infrastructure standardize to the OSGi specification, but not to create a new application model. Because this may lead to a non osgi compatiable bundle, IIUC, any bundle that wanna be used in geronimo must re-write to provide the additional mvn-style information. Why do you think the require-bundle is not a workable solution for (2) ? Rex. 2009/3/14 David Jencks david_jen...@yahoo.com On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't
[jira] Assigned: (GERONIMO-4588) Adding multiple server with the same host in monitoring portlet results in a sql error
[ https://issues.apache.org/jira/browse/GERONIMO-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-4588: - Assignee: Jarek Gawor (was: Ashish Jain) Adding multiple server with the same host in monitoring portlet results in a sql error -- Key: GERONIMO-4588 URL: https://issues.apache.org/jira/browse/GERONIMO-4588 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.4 Environment: Windows XP, Geronimo V2.1.4 Reporter: Ashish Jain Assignee: Jarek Gawor Fix For: 2.1.4 Attachments: geronimo-4588.patch Adding multiple server with same host in monitoring portlet results in a sql error. It seems the IP attribute in Servers table is defined to be unique. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4588) Adding multiple server with the same host in monitoring portlet results in a sql error
[ https://issues.apache.org/jira/browse/GERONIMO-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-4588: -- Affects Version/s: 2.2 Adding multiple server with the same host in monitoring portlet results in a sql error -- Key: GERONIMO-4588 URL: https://issues.apache.org/jira/browse/GERONIMO-4588 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.4, 2.2 Environment: Windows XP, Geronimo V2.1.4 Reporter: Ashish Jain Assignee: Jarek Gawor Fix For: 2.1.4 Attachments: geronimo-4588.patch Adding multiple server with same host in monitoring portlet results in a sql error. It seems the IP attribute in Servers table is defined to be unique. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-563) Start geronimo server in profiling mode
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682692#action_12682692 ] Delos Dai commented on GERONIMODEVTOOLS-563: Hi Marco, After investigation, I found there are some built-in monitor option for Tomcat, which you have seen. For geronimo or other server adapter, there should be a default option. But seems it's a TPTP bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=268996 Anyway, there is a workaround for this - before you profile on server, close the integrated agent controller. Here is the steps: window-preferences-agent controller-Integrated Agent-select Disable. Then, you can find the option in monitor tab. Hope it helps! Start geronimo server in profiling mode --- Key: GERONIMODEVTOOLS-563 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-563 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Environment: Windows XP Eclipse 3.4.2 Geronimo Server Adapter 2.1.3 Reporter: Marco Laponder Assignee: Tim McConnell Attachments: screenshot-1.jpg I am trying to start Geronimo in profiling mode from Eclipse. I added the server and can start it from eclipse. However when I want to start it in profiling mode by the 'Start server in profiling mode button' it opens the dialog 'Profile on Server' but on the monitor tabpage there are no options to select and the finish buttons stays disabled. When I do the same for the tomcat server I can select options like 'Execution Time','Memory Analysis' etc. Profiling with eclipse seems like a nice improvement to be able to profile the web applications on Geronimo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4588) Adding multiple server with the same host in monitoring portlet results in a sql error
[ https://issues.apache.org/jira/browse/GERONIMO-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4588. --- Resolution: Fixed Fix Version/s: 2.2 Committed the patch to trunk (revision 755280), branches/2.1 (revision 755279) and branches/2.1.4 (revision 755278). Thanks a lot! Adding multiple server with the same host in monitoring portlet results in a sql error -- Key: GERONIMO-4588 URL: https://issues.apache.org/jira/browse/GERONIMO-4588 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.4, 2.2 Environment: Windows XP, Geronimo V2.1.4 Reporter: Ashish Jain Assignee: Jarek Gawor Fix For: 2.1.4, 2.2 Attachments: geronimo-4588.patch Adding multiple server with same host in monitoring portlet results in a sql error. It seems the IP attribute in Servers table is defined to be unique. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4591) Email attachments name can not be retrieved
Email attachments name can not be retrieved --- Key: GERONIMO-4591 URL: https://issues.apache.org/jira/browse/GERONIMO-4591 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: specs Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4591) Email attachments name can not be retrieved
[
https://issues.apache.org/jira/browse/GERONIMO-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682701#action_12682701
]
Guillaume Nodet commented on GERONIMO-4591:
---
The following patch should work, but I'm waiting for a confirmation that it
actually works before committing it.
{code}
Index: src/main/java/javax/mail/internet/MimePartDataSource.java
===
--- src/main/java/javax/mail/internet/MimePartDataSource.java (revision
755277)
+++ src/main/java/javax/mail/internet/MimePartDataSource.java (working copy)
@@ -111,6 +111,13 @@
}
public String getName() {
+try {
+if (part instanceof MimeBodyPart) {
+return ((MimeBodyPart) part).getFileName();
+}
+} catch (MessagingException mex) {
+// ignore it
+}
return ;
}
Index: src/main/java/javax/mail/internet/MimeBodyPart.java
===
--- src/main/java/javax/mail/internet/MimeBodyPart.java (revision 755277)
+++ src/main/java/javax/mail/internet/MimeBodyPart.java (working copy)
@@ -296,7 +296,7 @@
public String getFileName() throws MessagingException {
// see if there is a disposition. If there is, parse off the filename
parameter.
-String disposition = getSingleHeader(Content-Disposition);
+String disposition = getDisposition();
String filename = null;
if (disposition != null) {
@@ -306,7 +306,7 @@
// if there's no filename on the disposition, there might be a name
parameter on a
// Content-Type header.
if (filename == null) {
-String type = getSingleHeader(Content-Type);
+String type = getContentType();
if (type != null) {
try {
filename = new ContentType(type).getParameter(name);
@@ -350,7 +350,7 @@
contentDisposition.setParameter(filename, name);
// serialize this back out and reset.
-setHeader(Content-Disposition, contentDisposition.toString());
+setDisposition(contentDisposition.toString());
// The Sun implementation appears to update the Content-type name
parameter too, based on
// another system property
{code}
Email attachments name can not be retrieved
---
Key: GERONIMO-4591
URL: https://issues.apache.org/jira/browse/GERONIMO-4591
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: specs
Reporter: Guillaume Nodet
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Jacc questions
Hi, Looks like with the Jacc API there is no easy way to set multiple types of handler data objects on the same thread at the same time (see PolicyContext.setHandlerData()). That is, if for example, if a servlet makes a ejb call, from within the ejb we won't be able to retrieve the HttpServletRequest object using the PolicyContext API since the HttpServletRequest object will be replaced with the ejb call info object on the thread. So what's the best way to deal with this problem? One way to solve it, it would to set the handler data object to some a Map and set the handler data objects on the map. That would work as long as nothing else calls PolicyContext.setHandlerData() and replaces the map with some other object. Another way to solve it, it would be to create a GeronimoPolicyContext class (or something like that) which would support setting multiple types of handler data objects on the same thread at the same time (e.g GeronimoPolicyContext.setHandlerData(key, data)) AND modify Geronimo's PolicyContextHandlers to use GeronimoPolicyContext to get the right object for the handler. But with this solution we might be ignoring what's set using PolicyContext.setHandlerData(). Thoughts? Jarek
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12682733#action_12682733 ] Joe Bohn commented on GERONIMO-4507: We need a patch for this in the next day or two or it will not make it into Geronimo 2.1.4. 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: Joe Bohn Priority: Minor Fix For: 2.1.4, 2.2 Attachments: locale-priority.patch, locale-priority_fix.patch, locale-priority_fix2_v22.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.
Re: Jacc questions
On Mar 17, 2009, at 10:30 AM, Jarek Gawor wrote:
Hi,
Looks like with the Jacc API there is no easy way to set multiple
types of handler data objects on the same thread at the same time (see
PolicyContext.setHandlerData()). That is, if for example, if a servlet
makes a ejb call, from within the ejb we won't be able to retrieve the
HttpServletRequest object using the PolicyContext API since the
HttpServletRequest object will be replaced with the ejb call info
object on the thread.
So what's the best way to deal with this problem?
One way to solve it, it would to set the handler data object to some a
Map and set the handler data objects on the map. That would work as
long as nothing else calls PolicyContext.setHandlerData() and replaces
the map with some other object.
Another way to solve it, it would be to create a GeronimoPolicyContext
class (or something like that) which would support setting multiple
types of handler data objects on the same thread at the same time (e.g
GeronimoPolicyContext.setHandlerData(key, data)) AND modify Geronimo's
PolicyContextHandlers to use GeronimoPolicyContext to get the right
object for the handler. But with this solution we might be ignoring
what's set using PolicyContext.setHandlerData().
Thoughts?
The alleged purpose :-) of the policy context handler data is to
provide context info for permission evaluation.
To me the main problem is that in this scenario:
servlet (servlet request)
ejb (ejb method params)
return to servlet (still have ejb method params)
the servlet can't use the servlet request to evaluate role-ref
permissions after the return from the ejb.
We could solve this problem by having each data handler have its own
thread local and when you call setHandlerData it delegates to all the
handlers which will store it if its the right type. This solves the
lots of info at once problem but prevents you from clearing the data
when you are done unless we have some custom object for each handler
that it recognizes to clear its own data.
So the handler would have a method like
public boolean setHandlerData(Object data) {
if (data instanceof HttpServletRequest) {
servletData.set(data);
return true;
} else if (data == CLEAR_OBJECT) {
servletData.remove();
return true;
}
return false;
}
But, basically I think this is a spec defect.
thanks
david jencks
Jarek
[BUILD] trunk: Failed for Revision: 755337
Geronimo Revision: 755337 built with tests included See the full build-1500.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090317/build-1500.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090317/unit-test-reports for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT 2) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT 2) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http
Geronimo 2.1.4 code freeze
I think we're at a point where we should freeze branches/2.1.4 in prep for a release. OpenEJB 3.0.1 is in the process of being released and the OpenJPA 1.2.1 vote should close tomorrow. Those were our two primary dependencies that we were waiting on. Please check with Jarek or me if you would like to integrate any additional changes into 2.1.4. We'll hopefully be able to produce a release candidate later this week. Thanks, Joe
[BUILD] trunk: Failed for Revision: 755450
Geronimo Revision: 755450 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090317/build-2100.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090317/unit-test-reports for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), ibiblio.org (http://repo.exist.com/maven2), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT 2) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), ibiblio.org (http://repo.exist.com/maven2), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.activemq -DartifactId=activemq-web-console -Dversion=5.3-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT 2) org.apache.activemq:activemq-web-console:war:5.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.plugins:activemq-webconsole:war:2.2-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), ibiblio.org (http://repo.exist.com/maven2), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/), codehaus-snapshots (http
Re: [OSGi] Support for RFC 124?
+1000 :-) Rex. 2009/3/17 Rick McGuire rick...@gmail.com It has been reworked much more that just the schema changes in the standardization process. A lot of the service dynamics have changed, there have been some fairly signification changes to type conversions and property injection, a brand-new metadata API, new namespace handler support, etc. Springsource hasn't even implemented some of the new features yet, so this was far from a rubber-stamp effort. Rick Guillaume Nodet wrote: RFC 124 is simply a ruberstamp around what Spring-DM provides. The only real difference afaik are a few changes in the schema (mostly the namespace and replacing bean by component. This does not remove the usefulness of it btw... 2009/3/17 Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com Folks, Any interest in support for RFC 124, A Component Model for OSGi? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Whence the geronimo kernel?
Thanks Lin, I know the Issues with reqriring bundle(3.13.3 of spec 4.1), and the main opposite point from the blog I think is just because of the refactor. I just want to make clear that, is there any situation we might meet the split packages or refactor a bundle frequently? At least, my eclipse 3.4's plugins always prefer to use require-bundle and seems no problem with that.. I am not saying that I am a funs of require-bundle, but I really hope the MF and geronimo-plugin.xml(for a single bundle) not have a relationship like the JEE app's deployment descriptor and geronimo deployment plan... Rex. 2009/3/17 Lin Sun linsun@gmail.com Rex, If you follow the discussion closely, I think David was just saying that he prefers to stay away from Require-Bundle for now, as the OSGi specification doesn't recommend people to use it, along with the probs people mentioned about it in the link I posted earlier. I also found these links interesting - http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html http://ekkes-corner.blogspot.com/2008/06/catch-22-logging-with-osgi-frameworks.html David, Some comments regarding #2, its essential to know what jars/bundles/plugins/modules are actually in your running system. I think OSGi framework provides the ability to display the currently running bundles, so there should be APIs to get that. For example, you type ss in equinox console to get the list of installed bundles: osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 14 ACTIVE org.osgi.impl.service.log_1.3.2.200902181055 17 RESOLVEDorg.osgi.impl.service.http_4.2.0.200902181209 18 INSTALLED org.osgi.test.cases.http_4.2.0.200902181210 OSGi framework also uses resolver to resolve bundles. For example, if I want to install Bundle A to the framework, and Bundle imports package AA, then when I install the bundle A, the OSGi framework uses the resolver to find out if there is any bundle that exports package AA. If so, bundle A will be marked as RESOLVED. Otherwise, Bundle A will be marked as INSTALLED. If you search resolver in the OSGi core spec, you'll see a couple of places that mention it. I recently took a look at the new OSGi bundle repository spec (RFC 112). It talks about the concept of Resolver and the interface Resolver It talks about scenarios where a user wants to install a bundle (that uses Import-Package), the server should be able to pull all its dependencies from the bundle repository (or repositories) on the fly using the resolver. This seems something we would need for geronimo. Lin On Tue, Mar 17, 2009 at 12:52 AM, Rex Wang rwo...@gmail.com wrote: At the moment I'm inclined to think that require-bundle is not a workable solution for (2) and so we might as well use import-package plus an osgi runtime that uses and requires explicit external dependency information such as provided by maven or geronimo-plugin.xml to choose what bundle to resolve to. From my point of view, I am not quite like this mix version, because we must maintain the related information in two different places, that will absolutely increase geronimo's complexity and some sorts of confusing on the dependency settings, not only to the developers but also the users. I think one of the purpose that we adopt OSGi is to make our server infrastructure standardize to the OSGi specification, but not to create a new application model. Because this may lead to a non osgi compatiable bundle, IIUC, any bundle that wanna be used in geronimo must re-write to provide the additional mvn-style information. Why do you think the require-bundle is not a workable solution for (2) ? Rex. 2009/3/14 David Jencks david_jen...@yahoo.com On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote: David Jencks wrote: I read the blog entry and discussion. The entire discussion is predicated on the idea that osgi is close to ideal as-is and we have no need to consider any other point of view. If you step back a bit I see two things clearly acknowledged by everyone: 1. its useful to be able to know what classes are needed to make a jar/bundle/plugin/module work and which classes are expected to be used elsewhere 2. its essential to know what jars/bundles/plugins/modules are actually in your running system In osgi-land, import-package and export-package supply (1), and require-bundle sort of helps with (2) but AFAICT right now doesn't support artifact aliasing In maven-land, the pom dependency tracking provides a pretty good solution for (2), including some support for overriding requirements through exclusions, but it's single-classloader model doesn't translate directly into an app server or osgi runtime In geronimo trunk we emphasize (2) and can actually assemble working servers using it, and
[jira] Commented: (GERONIMODEVTOOLS-562) Can't install plugin via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682879#action_12682879 ] Larry Zhang commented on GERONIMODEVTOOLS-562: -- Sorry for the patch error. I have created a patch both for 562 and 564,and attached it in 564. Can't install plugin via GEP Key: GERONIMODEVTOOLS-562 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-562 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.4 Environment: os:win 2003 JDK: 1.6 Reporter: viola.lu Assignee: Tim McConnell Attachments: 562.patch, sample-plugins.zip Steps: 1.Extract attached sample plugin file 2.In eclipse, right-click g server , choose open and click convert app to plugin, choose sample plugin location as local repository and click next, but no plugin is listed to install, so this also result in summary page can't display for server plugin manger But i can install it via admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1.4 code freeze
If possible, I wish that GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration is included in 2.1.4. Thanks ! Ivan 2009/3/18 Joe Bohn joe.b...@earthlink.net I think we're at a point where we should freeze branches/2.1.4 in prep for a release. OpenEJB 3.0.1 is in the process of being released and the OpenJPA 1.2.1 vote should close tomorrow. Those were our two primary dependencies that we were waiting on. Please check with Jarek or me if you would like to integrate any additional changes into 2.1.4. We'll hopefully be able to produce a release candidate later this week. Thanks, Joe -- Ivan
[jira] Commented: (GERONIMODEVTOOLS-564) Fail to create plugin via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682884#action_12682884 ] Tim McConnell commented on GERONIMODEVTOOLS-564: Hi Larry, thanks very much for consolidating these two patches. This patch looks much promising -- the patched class compiles, it was created from the root level, and when invoking the patched funciton I can now select any or all of the plugins to install !! I need to do some more testing with it tomorrow, but this is certainly a step in the right direction. Thanks again Fail to create plugin via GEP - Key: GERONIMODEVTOOLS-564 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.4 Environment: os:wind2003 jdk:1.5 Reporter: viola.lu Assignee: Tim McConnell Attachments: 562+564.patch, 564.patch Steps: 1.Define a G server runtime, and right-click to open it 2.Open plugin page, click convert app to plugin-choose any item you would like-next, all fields are empty, and fail to convert it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1.4 code freeze
Go ahead and integrate the fix. Regards, Joe Ivan wrote: If possible, I wish that GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration is included in 2.1.4. Thanks ! Ivan 2009/3/18 Joe Bohn joe.b...@earthlink.net mailto:joe.b...@earthlink.net I think we're at a point where we should freeze branches/2.1.4 in prep for a release. OpenEJB 3.0.1 is in the process of being released and the OpenJPA 1.2.1 vote should close tomorrow. Those were our two primary dependencies that we were waiting on. Please check with Jarek or me if you would like to integrate any additional changes into 2.1.4. We'll hopefully be able to produce a release candidate later this week. Thanks, Joe -- Ivan
[jira] Assigned: (GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan reassigned GERONIMO-4529: -- Assignee: Ivan (was: Gang Yin) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration Key: GERONIMO-4529 URL: https://issues.apache.org/jira/browse/GERONIMO-4529 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.1.4, 2.2 Environment: Windows XP JDK 1.5 Geronimo 2.2 SNAPSHOT 20090202 Reporter: Ivan Assignee: Ivan Fix For: 2.2 Attachments: fix-g4529-jeffyin.patch After stopping the corba component in the console, port 1050 is not released. Use command netstat or connect it with Eclipse Debug. Those two threads are still running. Yoko:Server:StartedThread. It seems it is still blocked on ServerSocket.accept method. And I could not start the Corba service in the admin console due to address already in use. 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-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682918#action_12682918 ] Ivan commented on GERONIMO-4529: Commit changes to 2.1.4 to rev 755478. Currently, I did not apply the patch to 2.1.5 snapshot and 2.2 snapshot, for the patch is a workaround way. I will open a JIRA in Yoko, maybe we could use the new version Yoko in the 2.1.5/2.2. Thanks for any comment ! Corba port 1050 is not released after stopping j2ee-corba-yoko configuration Key: GERONIMO-4529 URL: https://issues.apache.org/jira/browse/GERONIMO-4529 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.1.4, 2.2 Environment: Windows XP JDK 1.5 Geronimo 2.2 SNAPSHOT 20090202 Reporter: Ivan Assignee: Ivan Fix For: 2.2 Attachments: fix-g4529-jeffyin.patch After stopping the corba component in the console, port 1050 is not released. Use command netstat or connect it with Eclipse Debug. Those two threads are still running. Yoko:Server:StartedThread. It seems it is still blocked on ServerSocket.accept method. And I could not start the Corba service in the admin console due to address already in use. 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: (YOKO-428) TransientNameService does not save the orb while using initialize method
TransientNameService does not save the orb while using initialize method Key: YOKO-428 URL: https://issues.apache.org/jira/browse/YOKO-428 Project: Yoko - CORBA Server Issue Type: Bug Security Level: public (Regular issues) Components: orb core Affects Versions: v1.0.0 Reporter: Ivan Priority: Minor While creating a TransientNameService, and intialize it using method initialize, it does not save the used orb to its inner variable createdORB, so while calling the destory method, the orb is not destroyed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682919#action_12682919 ] Ivan commented on GERONIMO-4529: https://issues.apache.org/jira/browse/YOKO-428 is opened, I wish to keep this JIRA on, so that we could track it. Corba port 1050 is not released after stopping j2ee-corba-yoko configuration Key: GERONIMO-4529 URL: https://issues.apache.org/jira/browse/GERONIMO-4529 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.1.4, 2.2 Environment: Windows XP JDK 1.5 Geronimo 2.2 SNAPSHOT 20090202 Reporter: Ivan Assignee: Ivan Fix For: 2.2 Attachments: fix-g4529-jeffyin.patch After stopping the corba component in the console, port 1050 is not released. Use command netstat or connect it with Eclipse Debug. Those two threads are still running. Yoko:Server:StartedThread. It seems it is still blocked on ServerSocket.accept method. And I could not start the Corba service in the admin console due to address already in use. 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-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:comment-tabpanelfocusedCommentId=12682923#action_12682923 ] Gang Yin commented on GERONIMO-4507: As Kan Ogawa hadn't finished porting G-4484(back-end message display and localization) and G-4517(front-end message display and localization) to branch 2.1, so there is no need to provide a patch for branch 2.1.4 at all. Thanks Joe. 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: Joe Bohn Priority: Minor Fix For: 2.1.4, 2.2 Attachments: locale-priority.patch, locale-priority_fix.patch, locale-priority_fix2_v22.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.
