[BUILD] trunk: Failed for Revision: 826153
Geronimo Revision: 826153 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091016/build-2100.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091016/unit-test-reports -- 1 required artifact is missing. for artifact: org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://repository.apache.org/snapshots) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xmlbeans:jar:2.4.0_3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xmlbeans -Dversion=2.4.0_3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xmlbeans -Dversion=2.4.0_3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xmlbeans:jar:2.4.0_3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://repository.apache.org/snapshots) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) 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:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) 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.servicemix.bundles:org.apache.servicemix.bundles.xmlbeans:jar:2.4.0_3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xmlbeans -Dversion=2.4.0_3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xmlbeans -Dversion=2.4.0_3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xmlbeans:jar:2.4.0_3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://repository.apache.org/snapshots) at
[jira] Updated: (GERONIMO-4917) Figure out how to use ext and endorsed classpaths under felix/karaf and get our corba spec in there.
[ https://issues.apache.org/jira/browse/GERONIMO-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-4917: --- Description: We need to find out how osgi deals with ext/endorsed directories and use that for our corba spec jar. (was: We need to find out how osgi deals with ext/extensions directories and use that for our corba spec jar.) Summary: Figure out how to use ext and endorsed classpaths under felix/karaf and get our corba spec in there. (was: Figure out how to use ext and extensions classpaths under felix/karaf and get our corba spec in there.) > Figure out how to use ext and endorsed classpaths under felix/karaf and get > our corba spec in there. > > > Key: GERONIMO-4917 > URL: https://issues.apache.org/jira/browse/GERONIMO-4917 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > Fix For: 3.0 > > > We need to find out how osgi deals with ext/endorsed directories and use that > for our corba spec jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4836) Default Pluto URL parser could not hanle semicolon in the parameter values
[ https://issues.apache.org/jira/browse/GERONIMO-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4836. -- Resolution: Fixed This is fixed in geronimo, working with pluto folks for a better fix there. > Default Pluto URL parser could not hanle semicolon in the parameter values > -- > > Key: GERONIMO-4836 > URL: https://issues.apache.org/jira/browse/GERONIMO-4836 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, Tomcat >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Ivan > Fix For: 2.2 > > > While the input parameter contains semicolon, there will be some issues while > handlering those parameters. Seem that Pluto would ignore those parameters > after the semicolon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4566) Need extra servlet mappings for jetty and tomcat for welcome jsps compiled into servlets
[ https://issues.apache.org/jira/browse/GERONIMO-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4566. -- Resolution: Fixed This was fixed by the commits listed under "all" > Need extra servlet mappings for jetty and tomcat for welcome jsps compiled > into servlets > > > Key: GERONIMO-4566 > URL: https://issues.apache.org/jira/browse/GERONIMO-4566 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, Jetty, Tomcat >Affects Versions: 2.2, 3.0 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2, 3.0 > > > See http://jira.codehaus.org/browse/JETTY-936. We need to include at least a > servlet mapping something like: > > jsp.index_jsp > / > > until jetty fixes the default servlet. > This showed up because I deleted the uncompiled jsps. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4154) Converting Debugviews Portlet from Dojo 0.4->1.1.1
[ https://issues.apache.org/jira/browse/GERONIMO-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4154. -- Resolution: Duplicate Fix Version/s: 2.2 This project was re-jiraed as GERONIMO-4790 > Converting Debugviews Portlet from Dojo 0.4->1.1.1 > -- > > Key: GERONIMO-4154 > URL: https://issues.apache.org/jira/browse/GERONIMO-4154 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Ubuntu 7.10 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.2 > > > The conversion of the four components within debugview-portlet from Dojo 0.4 > widget system to Dojo 1.1.1's dijit system in attempt to upgrade Geronimo to > all 1.1.1 components. > 1) Classloaderview > 2) Dependencyview > 3) Jmxmanager > 4) JndiView -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4917) Figure out how to use ext and extensions classpaths under felix/karaf and get our corba spec in there.
Figure out how to use ext and extensions classpaths under felix/karaf and get our corba spec in there. -- Key: GERONIMO-4917 URL: https://issues.apache.org/jira/browse/GERONIMO-4917 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: osgi Affects Versions: 3.0 Reporter: David Jencks Fix For: 3.0 We need to find out how osgi deals with ext/extensions directories and use that for our corba spec jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: osgi >> trunk
Thanks Donald, I opened GERONIMO-4916 to track this, removed the old framework, and moved over the osgi framework from sandbox. Now we just have to get it all to work :-) thanks david jencks On Oct 16, 2009, at 12:30 PM, Donald Woods wrote: Branch of current pre-OSGi trunk has been created at - https://svn.apache.org/repos/asf/geronimo/server/branches/3.0_old/ Let the OSGi merge begin -Donald David Jencks wrote: I have the sandbox osgi framework working enough to start the geronimo plugins, so I'm planning to move this work into trunk so we can all pitch in more easily on getting the rest of geronimo running on osgi. There's one legal issue to take care of first, since I copied in some plexus code that is not clearly available under asl2. The code appears to have been derived from ant, so I'm going to see if we can get the same results by importing or using ant code. I think that Donald is planning to make a branch off of trunk for a convenient place to try out jpa2 stuff at least until we have the equivalent working under osgi. If you have any concerns about this please speak up! thanks david jencks
[jira] Closed: (GERONIMO-4916) move osgi framework in to replace pre-osgi framwork
[ https://issues.apache.org/jira/browse/GERONIMO-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4916. -- Resolution: Fixed remove old framework: rev 826072 move osgi based framework: rev 826073 > move osgi framework in to replace pre-osgi framwork > --- > > Key: GERONIMO-4916 > URL: https://issues.apache.org/jira/browse/GERONIMO-4916 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) > Components: core, osgi >Affects Versions: 3.0 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 3.0 > > > Issue for tracking commits that swap the pre-osgi framework out and the > osgi-based framework from my sandbox in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4916) move osgi framework in to replace pre-osgi framwork
move osgi framework in to replace pre-osgi framwork --- Key: GERONIMO-4916 URL: https://issues.apache.org/jira/browse/GERONIMO-4916 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: core, osgi Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Issue for tracking commits that swap the pre-osgi framework out and the osgi-based framework from my sandbox in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4913) Use pax mvn urls everywhere possible.
[ https://issues.apache.org/jira/browse/GERONIMO-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-4913: --- Fix Version/s: 3.0 > Use pax mvn urls everywhere possible. > - > > Key: GERONIMO-4913 > URL: https://issues.apache.org/jira/browse/GERONIMO-4913 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > Fix For: 3.0 > > > While running the server, we use pax mvn urls for bundle locations, but not > always while running tests and otherwise during the build. We should clean > this up to use mvn urls except for temporary bundles in the DeploymentContext. > The code that creates the non mvn: urls is in locateBundle methods in > SimpleConfigurationManager and DeploymentManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4909) How should we shut down plugin under osgi?
[ https://issues.apache.org/jira/browse/GERONIMO-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-4909: --- Fix Version/s: 3.0 > How should we shut down plugin under osgi? > -- > > Key: GERONIMO-4909 > URL: https://issues.apache.org/jira/browse/GERONIMO-4909 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > Fix For: 3.0 > > > ConfigurationActivator needs it's stop method to shut down the plugin. > Calling configurationManager.unload(id) is symmetrical with start and should > leave the configuration model in a consistent state, but resets the load > attribute in config.xml to false, which prevents restarting the server. > Just stopping and unloading the configuration gbean works fine but may leave > the configuration model (in the configuration manager) in an inconsistent > state. > This needs further investigation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4914) gogo commands for manipulating g. plugins
[ https://issues.apache.org/jira/browse/GERONIMO-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-4914: --- Fix Version/s: 3.0 > gogo commands for manipulating g. plugins > - > > Key: GERONIMO-4914 > URL: https://issues.apache.org/jira/browse/GERONIMO-4914 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > Fix For: 3.0 > > > We need some simple gogo commands for manipulating geronimo plugins - > listing, starting gbeans, stopping gbeans, etc. I started on this in a > geronimo-shell-base module. we might be able to adapt the gshell commands, > although I don't think groovy is necessary or appropriate here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4912) Should plugins be packed jar files or exploded?
[ https://issues.apache.org/jira/browse/GERONIMO-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-4912: --- Fix Version/s: 3.0 > Should plugins be packed jar files or exploded? > --- > > Key: GERONIMO-4912 > URL: https://issues.apache.org/jira/browse/GERONIMO-4912 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > Fix For: 3.0 > > > Currently the osgi framework only works with plugins packed as jar files, not > exploded jar files like the regular geronimo server. Since osgi can deal > with classpaths inside a jar file, I rather think that we should proceed > with this as standard practice for the rest of the server. However this will > mean moving the archiving functionality out of the car-maven-plugin and into > the deployer. > The alternative is to make sure that unpacked plugins actually work in osgi. > I didn't experiment with this at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4908) RMIClassLoader is not compatible with osgi
[ https://issues.apache.org/jira/browse/GERONIMO-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-4908: --- Fix Version/s: 3.0 > RMIClassLoader is not compatible with osgi > -- > > Key: GERONIMO-4908 > URL: https://issues.apache.org/jira/browse/GERONIMO-4908 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > Fix For: 3.0 > > > We have RMIClassLoaderSpiImpl in geronimo-kernel. However, RMIClassLoader > loads the spi impl using the system classloader. > (http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html) > So we'd have to get our impl into the system classloader unless osgi provides > an additional level of delegation in the system classloader. > For now I'm going to try not setting java.rmi.server.RMIClassLoaderSpi in > RMIRegistryService -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4911) osgi manifest for plugins is created in the car-maven-plugin, not the deployer
[ https://issues.apache.org/jira/browse/GERONIMO-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-4911: --- Fix Version/s: 3.0 > osgi manifest for plugins is created in the car-maven-plugin, not the deployer > -- > > Key: GERONIMO-4911 > URL: https://issues.apache.org/jira/browse/GERONIMO-4911 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > Fix For: 3.0 > > > Currently the deployer doesn't generate osgi metadata, the car-maven-plugin > does. This needs to be fixed so that its possible to deploy stuff directly > to geronimo without building a plugin with maven first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: osgi >> trunk
Branch of current pre-OSGi trunk has been created at - https://svn.apache.org/repos/asf/geronimo/server/branches/3.0_old/ Let the OSGi merge begin -Donald David Jencks wrote: I have the sandbox osgi framework working enough to start the geronimo plugins, so I'm planning to move this work into trunk so we can all pitch in more easily on getting the rest of geronimo running on osgi. There's one legal issue to take care of first, since I copied in some plexus code that is not clearly available under asl2. The code appears to have been derived from ant, so I'm going to see if we can get the same results by importing or using ant code. I think that Donald is planning to make a branch off of trunk for a convenient place to try out jpa2 stuff at least until we have the equivalent working under osgi. If you have any concerns about this please speak up! thanks david jencks
[jira] Updated: (GERONIMO-4915) SVN urls on the site is outdated/wrong
[ https://issues.apache.org/jira/browse/GERONIMO-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4915: - Description: Currently on the page: http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html The subversion URLs give 404 errors for these 3: http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin I'm not sure what they should be, as I have never seen the source and can't verify if this is in fact the correct URL, though it seems like it should be (in the same order): http://svn.apache.org/viewvc/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ http://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ https://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ was: Currently on the page: http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html The subversion URLs give 404 errors for these 3: http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin I'm not sure what they should be, as I have never seen the source and can't verify if this is in fact the correct URL, though it seems like it should be (in the same order): http://svn.apache.org/viewvc/geronimo/devtools/maven-plugins/trunk/ http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/ https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/ Updated the URLs to the correct ones. > SVN urls on the site is outdated/wrong > -- > > Key: GERONIMO-4915 > URL: https://issues.apache.org/jira/browse/GERONIMO-4915 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: geronimo-maven-plugin >Reporter: Quintin Beukes > > Currently on the page: > http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html > The subversion URLs give 404 errors for these 3: > http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin > http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin > geronimo-maven-plugin > https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin > geronimo-maven-plugin > I'm not sure what they should be, as I have never seen the source and can't > verify if this is in fact the correct URL, though it seems like it should be > (in the same order): > http://svn.apache.org/viewvc/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ > http://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ > https://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-598) Support builds on Linux x86_64 based systems
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766673#action_12766673 ] Donald Woods commented on GERONIMODEVTOOLS-598: --- Strange, as I never had a problem building GEP 2.1.x on a SLES10 x86_64 system (w/ GNome desktop) with the 32bit Eclipse. Which Linux distro are you using? > Support builds on Linux x86_64 based systems > > > Key: GERONIMODEVTOOLS-598 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-598 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 2.2.0 > Environment: Linux x86_64 >Reporter: Johannes Weberhofer >Assignee: Tim McConnell >Priority: Minor > Attachments: gep-2.2-build-on-x86.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4915) SVN urls on the site is outdated/wrong
SVN urls on the site is outdated/wrong -- Key: GERONIMO-4915 URL: https://issues.apache.org/jira/browse/GERONIMO-4915 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: geronimo-maven-plugin Reporter: Quintin Beukes Currently on the page: http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html The subversion URLs give 404 errors for these 3: http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin geronimo-maven-plugin I'm not sure what they should be, as I have never seen the source and can't verify if this is in fact the correct URL, though it seems like it should be (in the same order): http://svn.apache.org/viewvc/geronimo/devtools/maven-plugins/trunk/ http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/ https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 825874
Geronimo Revision: 825874 built with tests included See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091016/build-0900.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20091016 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 361 minutes 47 seconds [INFO] Finished at: Fri Oct 16 15:05:25 EDT 2009 [INFO] Final Memory: 1344M/1536M [INFO] TESTSUITE RESULTS (Failures only) = Assembly: tomcat = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091016/logs-0900-tomcat/ Booting Geronimo Kernel (in Java 1.6.0_10)... Module 1/75 org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car started in .000s Module 2/75 org.apache.geronimo.framework/jee-specs/3.0-SNAPSHOT/car started in .000s Module 3/75 org.apache.geronimo.plugins.classloaders/xbean-finder/3.0-SNAPSHOT/car started in .000s Module 4/75 org.apache.geronimo.framework/xmlbeans/3.0-SNAPSHOT/car started in .000s Module 5/75 org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car 2009-10-16 15:12:00,037 WARN [RMIRegistryService] RMI Registry failed 2009-10-16 15:12:00,039 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName="org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car,j2eeType=GBean,name=RMIRegistry" java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310) at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218) at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393) at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129) at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190) at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:68) at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) at org.apache.geronimo.kernel.rmi.RMIRegistryService.doStart(RMIRegistryService.java:72) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:538) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:377) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:190) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:546) 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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$c5d55a63.startConfiguration() at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:161) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstr
[jira] Created: (GERONIMO-4914) gogo commands for manipulating g. plugins
gogo commands for manipulating g. plugins - Key: GERONIMO-4914 URL: https://issues.apache.org/jira/browse/GERONIMO-4914 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: osgi Affects Versions: 3.0 Reporter: David Jencks We need some simple gogo commands for manipulating geronimo plugins - listing, starting gbeans, stopping gbeans, etc. I started on this in a geronimo-shell-base module. we might be able to adapt the gshell commands, although I don't think groovy is necessary or appropriate here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4913) Use pax mvn urls everywhere possible.
Use pax mvn urls everywhere possible. - Key: GERONIMO-4913 URL: https://issues.apache.org/jira/browse/GERONIMO-4913 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: osgi Affects Versions: 3.0 Reporter: David Jencks While running the server, we use pax mvn urls for bundle locations, but not always while running tests and otherwise during the build. We should clean this up to use mvn urls except for temporary bundles in the DeploymentContext. The code that creates the non mvn: urls is in locateBundle methods in SimpleConfigurationManager and DeploymentManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4912) Should plugins be packed jar files or exploded?
Should plugins be packed jar files or exploded? --- Key: GERONIMO-4912 URL: https://issues.apache.org/jira/browse/GERONIMO-4912 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: osgi Affects Versions: 3.0 Reporter: David Jencks Currently the osgi framework only works with plugins packed as jar files, not exploded jar files like the regular geronimo server. Since osgi can deal with classpaths inside a jar file, I rather think that we should proceed with this as standard practice for the rest of the server. However this will mean moving the archiving functionality out of the car-maven-plugin and into the deployer. The alternative is to make sure that unpacked plugins actually work in osgi. I didn't experiment with this at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4911) osgi manifest for plugins is created in the car-maven-plugin, not the deployer
osgi manifest for plugins is created in the car-maven-plugin, not the deployer -- Key: GERONIMO-4911 URL: https://issues.apache.org/jira/browse/GERONIMO-4911 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: osgi Affects Versions: 3.0 Reporter: David Jencks Currently the deployer doesn't generate osgi metadata, the car-maven-plugin does. This needs to be fixed so that its possible to deploy stuff directly to geronimo without building a plugin with maven first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4909) How should we shut down plugin under osgi?
[ https://issues.apache.org/jira/browse/GERONIMO-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766627#action_12766627 ] David Jencks commented on GERONIMO-4909: Configurations have more, or at least different, states than bundles expose through BundleActivator: ||bundles||plugins|| |resolved|plugin installed| |started|configuration gbean started| |--|configuration gbeans started| Whether starting the configuration gbean should automatically start the gbeans in the configuration is stored in the load alse in config.xml. Normally, stopping the configuration gbeans will indicate to geronimo that you want this attribute set to "false". If you stop a plugin bundle, you definitely want to stop the gbeans first. However, if you are shutting down the server, you don't want to change the attribute values. In general we need a better way to deal with this extra state. > How should we shut down plugin under osgi? > -- > > Key: GERONIMO-4909 > URL: https://issues.apache.org/jira/browse/GERONIMO-4909 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > > ConfigurationActivator needs it's stop method to shut down the plugin. > Calling configurationManager.unload(id) is symmetrical with start and should > leave the configuration model in a consistent state, but resets the load > attribute in config.xml to false, which prevents restarting the server. > Just stopping and unloading the configuration gbean works fine but may leave > the configuration model (in the configuration manager) in an inconsistent > state. > This needs further investigation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4908) RMIClassLoader is not compatible with osgi
[ https://issues.apache.org/jira/browse/GERONIMO-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766618#action_12766618 ] David Jencks commented on GERONIMO-4908: Jarek found that by putting our impl in a jar in lib it is loadable by the standard rm classloader framework. It is not clear to me whether this actually results in bundle classes being accessible through rmi. I guess we should leave this open until we know. > RMIClassLoader is not compatible with osgi > -- > > Key: GERONIMO-4908 > URL: https://issues.apache.org/jira/browse/GERONIMO-4908 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > > We have RMIClassLoaderSpiImpl in geronimo-kernel. However, RMIClassLoader > loads the spi impl using the system classloader. > (http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html) > So we'd have to get our impl into the system classloader unless osgi provides > an additional level of delegation in the system classloader. > For now I'm going to try not setting java.rmi.server.RMIClassLoaderSpi in > RMIRegistryService -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: October Board report
Last chance everyone, The board report needs to be sent in by Monday. So, if there is anything notable that was missed - please add it! Thanks, Jay Jay D. McHugh wrote: > Hello again everyone, > > I have made a couple of additional changes to the report. > > Please take a look (especially to the sections on the sandbox and > specifications) to make sure I haven't said anything that isn't correct. > > And remember - the changes should really be made before the 16th. > > So make your changes/additions soon. > > Thanks, > > Jay > > Jay D. McHugh wrote: >> Hello all, >> >> Every three months I resolve that I should keep a running tally of the >> important events in Geronimo so that it will be easier to make the >> quarterly reports. I'm still making the same resolution. >> >> But, here is a start to the report for October. There are a few items >> that are not yet resolved: >> >> Will there be a 2.2 release this quarter? >> Will the Blueprint sandbox get contributed to Aries? >> etc... >> >> So not everything can be nailed down now. But if there are any areas >> that are completely missing, please add them. >> >> http://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2009-10+-+October >> >> Thanks, >> >> Jay
[BUILD] branches/2.2: Failed for Revision: 825856
Geronimo Revision: 825856 built with tests included
See the full build-0800.log file at
http://people.apache.org/builds/geronimo/server/binaries/2.2/20091016/build-0800.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/2.2/20091016
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 42 minutes 22 seconds
[INFO] Finished at: Fri Oct 16 08:47:53 EDT 2009
[INFO] Final Memory: 322M/997M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/2.2/20091016/logs-0800-tomcat/
Assembly: jetty
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/2.2/20091016/logs-0800-jetty/
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty7-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-jetty7-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/2.2/testsuite/target/geronimo-jetty7-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty7-javaee5/2.2-SNAPSHOT/geronimo-jetty7-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/2.2/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/2.2/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:53.891
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/2.2/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/testing/testsuite-testing.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:23.415)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:39.709)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:46.879)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:23.713)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:21.550)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:23.924) Java
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:02:09.790)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:54.920)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:01:12.726)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:52.451)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:39.624)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:33.481)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:40.346)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:53.398)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:01:20.721)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:49.751)
[INFO] enterprise-testsuite/sec-client-tests RUNNING
[INFO] enterprise-testsuite/sec-client-tests SUCCESS (0:00:35.308)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:58.169)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:58.170)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:37.552)
[INFO] web-testsuite/test-2.5-servlets
[jira] Updated: (GERONIMO-4910) Problem in geronimo-javamail_1.4_spec
[
https://issues.apache.org/jira/browse/GERONIMO-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon von Janowsky updated GERONIMO-4910:
-
Description:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.java
in geronimo-javamail_1.4_spec-1.6.jar
method: connect(String host, int port, String user, String password)
{code:title=Service.java|borderStyle=solid}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol + ".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
try {
// HERE THE USER IS ALWAYS OVERWRITTEN
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{code}
With kind regards,
Simon von Janowsky
was:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
class: Service.java
method: connect(String host, int port, String user, String password)
{code:title=Service.java|borderStyle=solid}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol + ".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
try {
// HERE THE USER IS ALWAYS OVERWRITTEN
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{code}
With kind regards,
Simon von Janowsky
> Problem in geronimo-javamail_1.4_spec
> -
>
> Key: GERONIMO-4910
> URL: https://issues.apache.org/jira/browse/GERONIMO-4910
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
>Reporter: Simon von Janowsky
>
> When a url ist set to receive email, the username is extracted correctly
> using UrlName class, but when querying the imap server the system defined
> username is used instead.
> This is because the username in the connect Method in Service.java overrides
> the username from the url. See this code excerpt from javax.mail.Service.java
> in geronimo-javamail_1.4_spec-1.6.jar
> method: connect(String host, int port, String user, String password)
> {code:title=Service.java|borderStyle=solid}
> if (user == null) {
> // first choice is from the url, if we have
> if (url != null) {
>user = url.getUsername();
>// make sure we get the password from the url, if we can.
>if (password == null) {
> password = url.getPassword();
>}
>// user still null? We have several levels of properties to try yet
>if (user == null) {
> if (protocol != null) {
> user = session.getProperty("mail." + protocol + ".user");
> }
> }
> }
> // this may still be null...get the global mail property
> if (user == null) {
> user = session.getProperty("mail.user");
> }
> // finally, we try getting the system defined user name
> try {
> // HERE THE USER IS ALWAYS OVERWRITTEN
> user = System.getProperty("user.name");
> } catch (SecurityException e) {
> // we ignore this, and just us a null username.
> }
> }
> {code}
> W
[jira] Updated: (GERONIMO-4910) Problem in geronimo-javamail_1.4_spec
[
https://issues.apache.org/jira/browse/GERONIMO-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon von Janowsky updated GERONIMO-4910:
-
Description:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
class: Service.java
method: connect(String host, int port, String user, String password)
{code:title=Service.java|borderStyle=solid}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol + ".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
try {
// HERE THE USER IS ALWAYS OVERWRITTEN
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{code}
With kind regards,
Simon von Janowsky
was:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
class: Service.java
method: connect(String host, int port, String user, String password)
{code:title=Service.java|borderStyle=solid}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
try {
// HERE THE USER IS ALWAYS OVERWRITTEN
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{code}
With kind regards,
Simon von Janowsky
> Problem in geronimo-javamail_1.4_spec
> -
>
> Key: GERONIMO-4910
> URL: https://issues.apache.org/jira/browse/GERONIMO-4910
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
>Reporter: Simon von Janowsky
>
> When a url ist set to receive email, the username is extracted correctly
> using UrlName class, but when querying the imap server the system defined
> username is used instead.
> This is because the username in the connect Method in Service.java overrides
> the username from the url. See this code excerpt from
> javax.mail.Service.class in geronimo-javamail_1.4_spec-1.6.jar
> class: Service.java
> method: connect(String host, int port, String user, String password)
> {code:title=Service.java|borderStyle=solid}
> if (user == null) {
> // first choice is from the url, if we have
> if (url != null) {
>user = url.getUsername();
>// make sure we get the password from the url, if we can.
>if (password == null) {
> password = url.getPassword();
>}
>// user still null? We have several levels of properties to try yet
>if (user == null) {
> if (protocol != null) {
> user = session.getProperty("mail." + protocol + ".user");
> }
> }
> }
> // this may still be null...get the global mail property
> if (user == null) {
> user = session.getProperty("mail.user");
> }
[jira] Updated: (GERONIMO-4910) Problem in geronimo-javamail_1.4_spec
[
https://issues.apache.org/jira/browse/GERONIMO-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon von Janowsky updated GERONIMO-4910:
-
Description:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
class: Service.java
method: connect(String host, int port, String user, String password)
{code:title=Service.java|borderStyle=solid}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
try {
// HERE THE USER IS ALWAYS OVERWRITTEN
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{code}
With kind regards,
Simon von Janowsky
was:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
class: Service.java
method: connect(String host, int port, String user, String password)
{code:title=Service.java|borderStyle=solid}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
try {
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{code}
With kind regards,
Simon von Janowsky
> Problem in geronimo-javamail_1.4_spec
> -
>
> Key: GERONIMO-4910
> URL: https://issues.apache.org/jira/browse/GERONIMO-4910
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
>Reporter: Simon von Janowsky
>
> When a url ist set to receive email, the username is extracted correctly
> using UrlName class, but when querying the imap server the system defined
> username is used instead.
> This is because the username in the connect Method in Service.java overrides
> the username from the url. See this code excerpt from
> javax.mail.Service.class in geronimo-javamail_1.4_spec-1.6.jar
> class: Service.java
> method: connect(String host, int port, String user, String password)
> {code:title=Service.java|borderStyle=solid}
>if (user == null) {
> // first choice is from the url, if we have
> if (url != null) {
> user = url.getUsername();
> // make sure we get the password from the url, if we can.
> if (password == null) {
> password
[jira] Updated: (GERONIMO-4910) Problem in geronimo-javamail_1.4_spec
[
https://issues.apache.org/jira/browse/GERONIMO-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon von Janowsky updated GERONIMO-4910:
-
Description:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
class: Service.java
method: connect(String host, int port, String user, String password)
{code:title=Service.java|borderStyle=solid}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
try {
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{code}
With kind regards,
Simon von Janowsky
was:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
{quote}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
try {
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{quote}
With kind regards,
Simon von Janowsky
> Problem in geronimo-javamail_1.4_spec
> -
>
> Key: GERONIMO-4910
> URL: https://issues.apache.org/jira/browse/GERONIMO-4910
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
>Reporter: Simon von Janowsky
>
> When a url ist set to receive email, the username is extracted correctly
> using UrlName class, but when querying the imap server the system defined
> username is used instead.
> This is because the username in the connect Method in Service.java overrides
> the username from the url. See this code excerpt from
> javax.mail.Service.class in geronimo-javamail_1.4_spec-1.6.jar
> class: Service.java
> method: connect(String host, int port, String user, String password)
> {code:title=Service.java|borderStyle=solid}
>if (user == null) {
> // first choice is from the url, if we have
> if (url != null) {
> user = url.getUsername();
> // make sure we get the password from the url, if we can.
> if (password == null) {
> password = url.getPassw
[jira] Updated: (GERONIMO-4910) Problem in geronimo-javamail_1.4_spec
[
https://issues.apache.org/jira/browse/GERONIMO-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon von Janowsky updated GERONIMO-4910:
-
Description:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
{quote}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
try {
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{quote}
With kind regards,
Simon von Janowsky
was:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
{quote}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
try {
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{/quote}
With kind regards,
Simon von Janowsky
> Problem in geronimo-javamail_1.4_spec
> -
>
> Key: GERONIMO-4910
> URL: https://issues.apache.org/jira/browse/GERONIMO-4910
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
>Reporter: Simon von Janowsky
>
> When a url ist set to receive email, the username is extracted correctly
> using UrlName class, but when querying the imap server the system defined
> username is used instead.
> This is because the username in the connect Method in Service.java overrides
> the username from the url. See this code excerpt from
> javax.mail.Service.class in geronimo-javamail_1.4_spec-1.6.jar
> {quote}
> String password)">
>if (user == null) {
> // first choice is from the url, if we have
> if (url != null) {
> user = url.getUsername();
> // make sure we get the password from the url, if we can.
> if (password == null) {
> password = url.getPassword();
> }
> // user still null? We have several levels of properties to
> try yet
> if (user == null) {
> if (protocol != null) {
>
[jira] Updated: (GERONIMO-4910) Problem in geronimo-javamail_1.4_spec
[
https://issues.apache.org/jira/browse/GERONIMO-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon von Janowsky updated GERONIMO-4910:
-
Description:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
{quote}
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
try {
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
{/quote}
With kind regards,
Simon von Janowsky
was:
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
try {
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
With kind regards,
Simon von Janowsky
> Problem in geronimo-javamail_1.4_spec
> -
>
> Key: GERONIMO-4910
> URL: https://issues.apache.org/jira/browse/GERONIMO-4910
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: mail
>Reporter: Simon von Janowsky
>
> When a url ist set to receive email, the username is extracted correctly
> using UrlName class, but when querying the imap server the system defined
> username is used instead.
> This is because the username in the connect Method in Service.java overrides
> the username from the url. See this code excerpt from
> javax.mail.Service.class in geronimo-javamail_1.4_spec-1.6.jar
> {quote}
> String password)">
>if (user == null) {
> // first choice is from the url, if we have
> if (url != null) {
> user = url.getUsername();
> // make sure we get the password from the url, if we can.
> if (password == null) {
> password = url.getPassword();
> }
> // user still null? We have several levels of properties to
> try yet
> if (user == null) {
> if (protocol != null) {
> user = s
[jira] Created: (GERONIMO-4910) Problem in geronimo-javamail_1.4_spec
Problem in geronimo-javamail_1.4_spec
-
Key: GERONIMO-4910
URL: https://issues.apache.org/jira/browse/GERONIMO-4910
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: mail
Reporter: Simon von Janowsky
When a url ist set to receive email, the username is extracted correctly using
UrlName class, but when querying the imap server the system defined username
is used instead.
This is because the username in the connect Method in Service.java overrides
the username from the url. See this code excerpt from javax.mail.Service.class
in geronimo-javamail_1.4_spec-1.6.jar
if (user == null) {
// first choice is from the url, if we have
if (url != null) {
user = url.getUsername();
// make sure we get the password from the url, if we can.
if (password == null) {
password = url.getPassword();
}
// user still null? We have several levels of properties to
try yet
if (user == null) {
if (protocol != null) {
user = session.getProperty("mail." + protocol +
".user");
}
}
}
// this may still be null...get the global mail property
if (user == null) {
user = session.getProperty("mail.user");
}
// finally, we try getting the system defined user name
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
// HERE THE USER IS ALWAYS OVERWRITTEN
try {
user = System.getProperty("user.name");
} catch (SecurityException e) {
// we ignore this, and just us a null username.
}
}
With kind regards,
Simon von Janowsky
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-598) Support builds on Linux x86_64 based systems
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766484#action_12766484 ] Delos Dai commented on GERONIMODEVTOOLS-598: Thanks, Johannes! I will find a linux x86_64 based systems to verify your patch. > Support builds on Linux x86_64 based systems > > > Key: GERONIMODEVTOOLS-598 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-598 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 2.2.0 > Environment: Linux x86_64 >Reporter: Johannes Weberhofer >Assignee: Tim McConnell >Priority: Minor > Attachments: gep-2.2-build-on-x86.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Wiki link to current version page
I've also found that the search engines list very similar results for most searches (from my experience at least). So usually optimizing for Google ends up giving similar effects for all 3 major indexes (Yahoo/Live/Google). Beyond this, most other search engines just feed from one of these 3 indexes. The other "real" indexes are mostly insignificant. Quintin Beukes On Fri, Oct 16, 2009 at 11:08 AM, Quintin Beukes wrote: > I definitely recommend looking into an archive if possible. You should > even be able to leave the documentation.html page's links the same, > only changing the old docs to be hosted on another domain. If at all > possible this would be a good solution to ensure the latest docs have > as much indexed on google as possible. > > Quintin Beukes > > > > On Fri, Oct 16, 2009 at 3:39 AM, Ellen Tang wrote: >> Hi Quintin, >> >> Thank you for your advice. That's very useful for us. I'll look into SEO and >> try to make our pages better. >> >> Best regards, >> >> Ellen >> >> 2009/10/14 Quintin Beukes >>> >>> Futher, if the old docs are taken out, it would leave a structure >>> that's much more focused on a the newest version, and thus reduce the >>> likeliness of GoogleBot seeing the pages as being too similar. >>> GoogleBot is very sensitive with this and sometimes sees 2 completely >>> irrelevant pages as being similar. I've found on 2 occasions that >>> changing the wording on one page could cause another page to suddenly >>> appear with the next index. This could be coincidence, as many reasons >>> could cause a page to become indexed, but the similarity seems most >>> probably since looking at the 2 pages you could understand how a bot >>> could see them as similar. >>> >>> Further, updating the documentation with basic SEO in mind, and >>> improving the link webs should help get more pages indexed - and >>> possibly even listed higher. >>> >>> Quintin Beukes >>> >>> >>> >>> On Wed, Oct 14, 2009 at 5:19 PM, Quintin Beukes >>> wrote: >>> > The 2.2 docs are on google. In fact, all the versions are there. By >>> > default it only lists 1/2 similar pages, and the rest can be viewed by >>> > clicking on the "more results" link. >>> > >>> > From what I could see on the pages, the reason 1.1 docs are listed >>> > first is an SEO issue, in that the 1.1 docs contain the word Geronimo >>> > more, and has a ranked page linking to it. To host all the >>> > documentation online would make a for a major SEO task added onto the >>> > list. Maybe the best would be to add the old docs into an "archive" >>> > (another domain would be best), link into the archive, and have only >>> > the latest docs actually stored on the xwiki.apache.org domain. I >>> > don't know if this is possible, but it should definitely clear up the >>> > documentation issue. >>> > >>> > If you're unlucky the archive ends up ranking higher than the original >>> > and you're back to where you started, though I think that would be >>> > unlikely if there is a link trail to Geronimo from the xwiki root, and >>> > back up wards (and the same for all apps). This should keep the rank >>> > tree farely high, and an archive would be unlikely to overtake it. >>> > >>> > I'm no SEO expert, so this might not be the best advice, but it would >>> > be what I would have done. >>> > >>> > Quintin Beukes >>> > >>> > >>> > >>> > On Wed, Oct 14, 2009 at 5:02 AM, Ellen Tang >>> > wrote: >>> >> Hi, I found that the "I'm feeling lucky" function only takes you to the >>> >> first website listed in Google responding to your query. This is why >>> >> you are >>> >> directed to 1.1 docs instead of 2.1. But I do see the problem that 2.2 >>> >> docs >>> >> are not listed in Google. >>> >> >>> >> I've seen the Confluence help pages with the links of the latest >>> >> version as >>> >> you suggested. It works very well on the Confluence websites. I think >>> >> it's a >>> >> very good function but yet takes a lot effort to implement because we >>> >> have >>> >> so many pages and versions of G docs right now. Plus, once we have a >>> >> new >>> >> release, all the links need to be updated. As discussed with Jeff, we >>> >> can >>> >> first try to make our latest docs display in Google. >>> >> >>> >> Please let us know if you have any suggestions for that. Thank you! >>> >> >>> >> Best regards, >>> >> Ellen >>> >> >>> >> 2009/10/1 Juergen Weber >>> >>> >>> >>> Fixing the links doesn't seem to be the general solution, >>> >>> e.g. with >>> >>> geronimo ra.xml and "I'm feeling lucky" you get the 1.1 docs, even if >>> >>> google >>> >>> knows the 2.1 docs. >>> >>> There should be a friendly big red box on old pages "There exists a >>> >>> more >>> >>> recent version of this page" with a link to it. >>> >>> >>> >>> Greetings, Juergen >>> >>> >>> >>> >>> >>> Ellen Tang-2 wrote: >>> >>> > >>> >>> > I've tried to find the page of the same topic (Daytrader) in >>> >>> > documentation >>> >>> > v2.1 by changing the link directly from >>> >>> > http://cwiki.apache.or
Re: Wiki link to current version page
I definitely recommend looking into an archive if possible. You should even be able to leave the documentation.html page's links the same, only changing the old docs to be hosted on another domain. If at all possible this would be a good solution to ensure the latest docs have as much indexed on google as possible. Quintin Beukes On Fri, Oct 16, 2009 at 3:39 AM, Ellen Tang wrote: > Hi Quintin, > > Thank you for your advice. That's very useful for us. I'll look into SEO and > try to make our pages better. > > Best regards, > > Ellen > > 2009/10/14 Quintin Beukes >> >> Futher, if the old docs are taken out, it would leave a structure >> that's much more focused on a the newest version, and thus reduce the >> likeliness of GoogleBot seeing the pages as being too similar. >> GoogleBot is very sensitive with this and sometimes sees 2 completely >> irrelevant pages as being similar. I've found on 2 occasions that >> changing the wording on one page could cause another page to suddenly >> appear with the next index. This could be coincidence, as many reasons >> could cause a page to become indexed, but the similarity seems most >> probably since looking at the 2 pages you could understand how a bot >> could see them as similar. >> >> Further, updating the documentation with basic SEO in mind, and >> improving the link webs should help get more pages indexed - and >> possibly even listed higher. >> >> Quintin Beukes >> >> >> >> On Wed, Oct 14, 2009 at 5:19 PM, Quintin Beukes >> wrote: >> > The 2.2 docs are on google. In fact, all the versions are there. By >> > default it only lists 1/2 similar pages, and the rest can be viewed by >> > clicking on the "more results" link. >> > >> > From what I could see on the pages, the reason 1.1 docs are listed >> > first is an SEO issue, in that the 1.1 docs contain the word Geronimo >> > more, and has a ranked page linking to it. To host all the >> > documentation online would make a for a major SEO task added onto the >> > list. Maybe the best would be to add the old docs into an "archive" >> > (another domain would be best), link into the archive, and have only >> > the latest docs actually stored on the xwiki.apache.org domain. I >> > don't know if this is possible, but it should definitely clear up the >> > documentation issue. >> > >> > If you're unlucky the archive ends up ranking higher than the original >> > and you're back to where you started, though I think that would be >> > unlikely if there is a link trail to Geronimo from the xwiki root, and >> > back up wards (and the same for all apps). This should keep the rank >> > tree farely high, and an archive would be unlikely to overtake it. >> > >> > I'm no SEO expert, so this might not be the best advice, but it would >> > be what I would have done. >> > >> > Quintin Beukes >> > >> > >> > >> > On Wed, Oct 14, 2009 at 5:02 AM, Ellen Tang >> > wrote: >> >> Hi, I found that the "I'm feeling lucky" function only takes you to the >> >> first website listed in Google responding to your query. This is why >> >> you are >> >> directed to 1.1 docs instead of 2.1. But I do see the problem that 2.2 >> >> docs >> >> are not listed in Google. >> >> >> >> I've seen the Confluence help pages with the links of the latest >> >> version as >> >> you suggested. It works very well on the Confluence websites. I think >> >> it's a >> >> very good function but yet takes a lot effort to implement because we >> >> have >> >> so many pages and versions of G docs right now. Plus, once we have a >> >> new >> >> release, all the links need to be updated. As discussed with Jeff, we >> >> can >> >> first try to make our latest docs display in Google. >> >> >> >> Please let us know if you have any suggestions for that. Thank you! >> >> >> >> Best regards, >> >> Ellen >> >> >> >> 2009/10/1 Juergen Weber >> >>> >> >>> Fixing the links doesn't seem to be the general solution, >> >>> e.g. with >> >>> geronimo ra.xml and "I'm feeling lucky" you get the 1.1 docs, even if >> >>> google >> >>> knows the 2.1 docs. >> >>> There should be a friendly big red box on old pages "There exists a >> >>> more >> >>> recent version of this page" with a link to it. >> >>> >> >>> Greetings, Juergen >> >>> >> >>> >> >>> Ellen Tang-2 wrote: >> >>> > >> >>> > I've tried to find the page of the same topic (Daytrader) in >> >>> > documentation >> >>> > v2.1 by changing the link directly from >> >>> > http://cwiki.apache.org/GMOxDOC20/daytrader.html to >> >>> > http://cwiki.apache.org/GMOxDOC21/daytrader.html . The page does >> >>> > open >> >>> > and >> >>> > has correct contents, but when I tried to find the link of the same >> >>> > topic >> >>> > in >> >>> > the table of contents of v2.1 documentation ( >> >>> > http://cwiki.apache.org/GMOxDOC21/documentation.html ), I couldn't >> >>> > find >> >>> > the >> >>> > link for the "Daytrader" page, which does exist. >> >>> > >> >>> > I guess that this is why the google search can't find the page of >> >>> > "Daytrade
Re: More OSGi progress
I tried to follow the steps that Rex provided, somehow I ran into a build
failure when mvn install framework in the final step. Then I tried mvn clean
install -Dmaven.test.skip=true, still no luck.
Here is the error msg I noticed, any workaround to bypass the exception?
Thanks in advance.
Jeff C
[INFO]
[INFO] Building Geronimo Build Support :: Plugin
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [groovy:generateStubs {execution: default}]
[WARN] Failed to load provider from:
org.codehaus.groovy.maven.runtime.loader.defaultproviderloa...@31103110
java.lang.NullPointerException
org.codehaus.groovy.maven.runtime.loader.DefaultProviderLoader.findProviders(DefaultProviderLoader.java:67)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderLoader.load(DefaultProviderLoader.java:45)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.load(DefaultProviderSelector.java:192)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.discover(DefaultProviderSelector.java:154)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.register(DefaultProviderSelector.java:98)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderSelector.select(DefaultProviderSelector.java:47)
org.codehaus.groovy.maven.runtime.loader.DefaultProviderManager.select(DefaultProviderManager.java:91)
org.codehaus.groovy.maven.plugin.ProviderMojoSupport.provider(ProviderMojoSupport.java:107)
org.codehaus.groovy.maven.plugin.ComponentMojoSupport.doExecute(ComponentMojoSupport.java:58)
org.codehaus.groovy.maven.plugin.MojoSupport.execute(MojoSupport.java:69)
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
java.lang.reflect.Method.invoke(Method.java:599)
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
org.codehaus.classworlds.Launcher.main(Launcher.java:375)
..
[ERROR] BUILD FAILURE
[INFO]
[INFO] Dependencies have changed:
Added dependencies are saved here:
/home/jeffchi/Geronimo/SourceCode/sandbox/framework/configs/geronimo-gbean-deployer-bootstrap/src/main/history/dependencies.added.xml
Tree listing is saved here:
/home/jeffchi/Geronimo/SourceCode/sandbox/framework/configs/geronimo-gbean-deployer-bootstrap/src/main/history/treeListing.xml
Delete
/home/jeffchi/Geronimo/SourceCode/sandbox/framework/configs/geronimo-gbean-deployer-bootstrap/src/main/history/dependencies.xml
if you are happy with the dependency changes.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 3 minutes 18 seconds
[INFO] Finished at: Fri Oct 16 10:56:00 CST 2009
[INFO] Final Memory: 201M/387M
[INFO]
On Thu, Oct 15, 2009 at 4:53 PM, Rex Wang wrote:
> I just built dj's sandbox framework successfully, here is my footprint.
> Hope this helps for the following guys, and also thanks for the clues above!
>
> my env:
> windowxp
> maven2.2.1
> jdk6
> sandbox rev825381
>
> checkout sandbox ramework
> ps: modify pom.xml(xmlbeans denp: 2.4.0_2-SNAPSHOT -> 2.4.0_3-SNAPSHOT)
>
> checkout servicemix
> ps:
> add djencks patch to xstream-1.3/pom.xml
> build root pom.xml
> build: jaxb
[jira] Commented: (GERONIMO-4909) How should we shut down plugin under osgi?
[ https://issues.apache.org/jira/browse/GERONIMO-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766471#action_12766471 ] Ivan commented on GERONIMO-4909: >From the beginning, we are trying to match the Configuration lifecycle to the >bundle lifecycle, it brought us too much issues. Since currently Geronimo >Kernel is still there, shall we treat them separately. While starting the bundle, preload the ConfigurationData, the most reason to do this is for having a chance to mantaine an artifactid -> bundleContext map, if there is another way to do it, we would do nothing. While the bundle is active, we could do any configuration lifecycle operations, it will not affect the bundle's status, it only changes Geronimo repository. While stopping the bundle, we also stop/unload the configuration. While uninstalling the bundle, we will missing :-) > How should we shut down plugin under osgi? > -- > > Key: GERONIMO-4909 > URL: https://issues.apache.org/jira/browse/GERONIMO-4909 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > > ConfigurationActivator needs it's stop method to shut down the plugin. > Calling configurationManager.unload(id) is symmetrical with start and should > leave the configuration model in a consistent state, but resets the load > attribute in config.xml to false, which prevents restarting the server. > Just stopping and unloading the configuration gbean works fine but may leave > the configuration model (in the configuration manager) in an inconsistent > state. > This needs further investigation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-4909) How should we shut down plugin under osgi?
[ https://issues.apache.org/jira/browse/GERONIMO-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766471#action_12766471 ] Ivan edited comment on GERONIMO-4909 at 10/16/09 1:27 AM: -- >From the beginning, we are trying to match the Configuration lifecycle to the >bundle lifecycle, it brought us too much issues. Since currently Geronimo >Kernel is still there, shall we treat them separately. While starting the bundle, preload the ConfigurationData, the most reason to do this is for having a chance to mantaine an artifactid -> bundleContext map, if there is another way to do it, we would do nothing. While the bundle is active, we could do any configuration lifecycle operations, it will not affect the bundle's status, it only changes Geronimo repository. While stopping the bundle, we also stop/unload the configuration. While uninstalling the bundle, we will stop/unload/uninstall the configuration. Just an idea, not sure anything importand is missing :-) was (Author: xuhaihong): From the beginning, we are trying to match the Configuration lifecycle to the bundle lifecycle, it brought us too much issues. Since currently Geronimo Kernel is still there, shall we treat them separately. While starting the bundle, preload the ConfigurationData, the most reason to do this is for having a chance to mantaine an artifactid -> bundleContext map, if there is another way to do it, we would do nothing. While the bundle is active, we could do any configuration lifecycle operations, it will not affect the bundle's status, it only changes Geronimo repository. While stopping the bundle, we also stop/unload the configuration. While uninstalling the bundle, we will missing :-) > How should we shut down plugin under osgi? > -- > > Key: GERONIMO-4909 > URL: https://issues.apache.org/jira/browse/GERONIMO-4909 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: David Jencks > > ConfigurationActivator needs it's stop method to shut down the plugin. > Calling configurationManager.unload(id) is symmetrical with start and should > leave the configuration model in a consistent state, but resets the load > attribute in config.xml to false, which prevents restarting the server. > Just stopping and unloading the configuration gbean works fine but may leave > the configuration model (in the configuration manager) in an inconsistent > state. > This needs further investigation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-598) Support builds on Linux x86_64 based systems
Support builds on Linux x86_64 based systems Key: GERONIMODEVTOOLS-598 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-598 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.2.0 Environment: Linux x86_64 Reporter: Johannes Weberhofer Assignee: Tim McConnell Priority: Minor Attachments: gep-2.2-build-on-x86.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-598) Support builds on Linux x86_64 based systems
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johannes Weberhofer updated GERONIMODEVTOOLS-598: - Attachment: gep-2.2-build-on-x86.diff > Support builds on Linux x86_64 based systems > > > Key: GERONIMODEVTOOLS-598 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-598 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 2.2.0 > Environment: Linux x86_64 >Reporter: Johannes Weberhofer >Assignee: Tim McConnell >Priority: Minor > Attachments: gep-2.2-build-on-x86.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4902) need license file modifications for imported plexus code in osgi sandbox modules/geronimo-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-4902. -- Resolution: Fixed Fixed in rev 825791 by using ant 1.7.0 code instead of plexus. > need license file modifications for imported plexus code in osgi sandbox > modules/geronimo-plugin > > > Key: GERONIMO-4902 > URL: https://issues.apache.org/jira/browse/GERONIMO-4902 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 3.0 >Reporter: David Jencks >Assignee: Kevan Miller > Fix For: 3.0 > > > In order to avoid giant problems with plexus invasiveness I copied the plexus > code we need to build archives into geronimo-plugin and modified it to not > pull in all of the plexus infrastructure. We need to find a way to eliminate > this code or fix the legal files. > rev 821961, > https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/osgi/framework > Kevan, if you don't want to do this unassign it -- I thought you might be the > best at figuring out what we need. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GEP 2.2
I was following the building guid on
http://cwiki.apache.org/GMOxDOC21/how-to-build-geronimo-eclipse-plugin-from-source.html#HowtoBuildGeronimoEclipsePluginfromSource-BuildingSource,
which says, skipping the test is not reccomented. However, I was already using
the resulting jars. The latest builds are working great with eclipse 3.5.1 /
Geronimo 2.1.
Thank you for the information that the testsuite is broken, so I know it's not
my system's fault.
Best regards,
Johannes
Am 16.10.2009 03:40, schrieb Delos:
Are you building GEP testsuite? I don't know why you build GEP
testsuite. Indeed, there is some issues in current testsuite.
But if you only want to get the latest GEP, you don't have to build the
testsuite, just "mvn clean install" under trunk.
BTW, the latest build of GEP can be downloaded from the unstable site
http://people.apache.org/dist/geronimo/eclipse/unstable/2.2.0/
Hope it helps!
2009/10/16 Johannes Weberhofer, Weberhofer GmbH mailto:off...@weberhofer.at>>
It's
Path: .
URL:
http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/trunk
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 825495
Node Kind: directory
Schedule: normal
Last Changed Author: delos
Last Changed Rev: 824225
Last Changed Date: 2009-10-12 06:59:59 +0200 (Mon, 12 Oct 2009)
Hope, it helps!
Johannes
Am 15.10.2009 21:16, schrieb Quintin Beukes:
Can you please run and paste "svn info" from the route of your
checkout.
Quintin Beukes
On Thu, Oct 15, 2009 at 4:18 PM, Johannes Weberhofer, Weberhofer
GmbH
mailto:off...@weberhofer.at>> wrote:
Building the current 2.2 version of the trunk I'm constantly
getting the
following error:
[INFO]
[INFO] Building Geronimo Eclipse Plugin :: Testsuite :: Launcher
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file-set:
/srv/project/autobuild/gep/trunk/testsuite/launcher (included:
[launcher/.metadata, launcher/eclipse, launcher/results,
launcher/server_v2.2, launcher/server_v2.1,
launcher/server_v2.0,
launcher/workspace], excluded: [])
[INFO] [buildnumber:create {execution: default}]
[INFO] Storing buildNumber: 20091015161556 at timestamp:
1255616156287
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing
/srv/project/autobuild/gep/trunk/testsuite/launcher/pom.xml to
/srv/downloads/maven/org/apache/geronimo/devtools/testsuite-launcher/2.2.0/testsuite-launcher-2.2.0.pom
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:test' is
invalid. It
will be ignored for artifact resolution. Reason: Not a
v4.0.0 POM. for
project org.jvnet.staxex:stax-ex at
/srv/downloads/maven/org/jvnet/staxex/stax-ex/1.0/stax-ex-1.0.pom
[INFO] [antrun:run {execution: run-testsuite}]
[INFO] Executing tasks
Is there any resolution for that issue?
Best regards,
Johannes
--
|-
| weberhofer GmbH | Johannes Weberhofer
| information technologies
| Austria, 1080 Wien, Blindengasse 52/3
|
| Firmenbuch: 225566s, Handelsgericht Wien
| UID: ATU55277701
|
| phone : +43 (0)1 5454421 0| email: off...@weberhofer.at
| fax : +43 (0)1 5454421 19 | web : http://weberhofer.at
| mobile: +43 (0)699 11998315
|--->>
--
Best Regards,
Delos
[BUILD] trunk: Failed for Revision: 825722
Geronimo Revision: 825722 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091016/build-2100.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20091016 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 370 minutes 33 seconds [INFO] Finished at: Fri Oct 16 03:12:38 EDT 2009 [INFO] Final Memory: 1345M/1536M [INFO] TESTSUITE RESULTS (Failures only) = Assembly: tomcat = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091016/logs-2100-tomcat/ Booting Geronimo Kernel (in Java 1.6.0_10)... Module 1/75 org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car started in .001s Module 2/75 org.apache.geronimo.framework/jee-specs/3.0-SNAPSHOT/car started in .000s Module 3/75 org.apache.geronimo.plugins.classloaders/xbean-finder/3.0-SNAPSHOT/car started in .000s Module 4/75 org.apache.geronimo.framework/xmlbeans/3.0-SNAPSHOT/car started in .000s Module 5/75 org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car 2009-10-16 03:31:21,911 WARN [RMIRegistryService] RMI Registry failed 2009-10-16 03:31:21,912 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName="org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car,j2eeType=GBean,name=RMIRegistry" java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310) at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218) at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393) at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129) at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190) at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:68) at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) at org.apache.geronimo.kernel.rmi.RMIRegistryService.doStart(RMIRegistryService.java:72) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:538) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:377) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:190) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:546) 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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$aaf84f1c.startConfiguration() at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:161) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstr
