Re: Issues running Tuscany applications in Geronimo 2.1.3
Thanks. that solved the problem !!! On Sun, Sep 28, 2008 at 6:49 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Sep 26, 2008, at 3:47 AM, Luciano Resende wrote: I'm trying to bringup a Tuscany application in Geronimo 2.1.3, and after fixing some TLD issues and JAXB dependency conflict issues, I still can't successfully start my Tuscany application (e.g calculator-ws-webapp) and the logs are showing the following classCastException. Any ideas and possible workarounds ? Luciano, I've created TUSCANY-2622 (https://issues.apache.org/jira/browse/TUSCANY-2622) and attached a patch to the geronimo-web.xml deployment plan being used by the alert-aggregator-webapp. The patch removes inverse-classloading and uses hidden-classes filters, instead. I ran tests with the updated deployment plan, and things seemed to work pretty well for me. --kevan -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
[BUILD] trunk: Failed for Revision: 700001
Geronimo Revision: 71 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 85 minutes 31 seconds [INFO] Finished at: Mon Sep 29 04:30:42 EDT 2008 [INFO] Final Memory: 394M/921M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929/logs-0300-tomcat/test.log Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/75 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car started in .000s Module 2/75 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car started in .000s Module 3/75 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car started in .963s Module 4/75 org.apache.geronimo.plugins.classloaders/geronimo-javaee-deployment_1.1MR3_spec/2.2-SNAPSHOT/car started in .000s Module 5/75 org.apache.geronimo.framework/plugin/2.2-SNAPSHOT/car started in .716s Module 6/75 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car started in .000s Module 7/75 org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car started in .361s Module 8/75 org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car started in .259s Module 9/75 org.apache.geronimo.configs/j2ee-server/2.2-SNAPSHOT/car started in .061s Module 10/75 org.apache.geronimo.framework/transformer-agent/2.2-SNAPSHOT/car started in .000s Module 11/75 org.apache.geronimo.plugins.classloaders/geronimo-schema-jee_5/2.2-SNAPSHOT/car started in .000s Module 12/75 org.apache.geronimo.configs/webservices-common/2.2-SNAPSHOT/car started in .000s Module 13/75 org.apache.geronimo.configs/transaction/2.2-SNAPSHOT/car started in .257s Module 14/75 org.apache.geronimo.framework/server-security-config/2.2-SNAPSHOT/car started in .075s Module 15/75 org.apache.geronimo.configs/derby/2.2-SNAPSHOT/car started in .000s Module 16/75 org.apache.geronimo.configs/system-database/2.2-SNAPSHOT/car started in 5.173s Module 17/75 org.apache.geronimo.configs/activemq-broker/2.2-SNAPSHOT/car started in 2.262s Module 18/75 org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car started in .008s Module 19/75 org.apache.geronimo.plugins.classloaders/xbean-finder/2.2-SNAPSHOT/car started in .000s Module 20/75 org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car 04:36:40,094 WARN [service] Property strictPooling not supported by DefaultStatelessContainer 04:36:40,094 WARN [service] Property timeout not supported by DefaultStatelessContainer 04:36:40,095 WARN [service] Property poolSize not supported by DefaultStatelessContainer 04:36:40,215 WARN [service] Property Cache not supported by DefaultStatefulContainer 04:36:40,216 WARN [service] Property Passivator not supported by DefaultStatefulContainer 04:36:40,216 WARN [service] Property TimeOut not supported by DefaultStatefulContainer 04:36:40,216 WARN [service] Property PoolSize not supported by DefaultStatefulContainer 04:36:40,216 WARN [service] Property BulkPassivate not supported by DefaultStatefulContainer 04:36:40,216 WARN [service] Property capacity not supported by DefaultStatefulContainer 04:36:40,216 WARN [service] Property timeout not supported by DefaultStatefulContainer 04:36:40,217 WARN [service] Property bulkPassivate not supported by DefaultStatefulContainer 04:36:40,263 WARN [service] Property AccessTimeout not supported by DefaultBMPContainer started in 1.035s Module 21/75 org.apache.geronimo.configs/axis/2.2-SNAPSHOT/car started in .134s Module 22/75 org.apache.geronimo.configs/axis2/2.2-SNAPSHOT/car started in .000s Module 23/75 org.apache.geronimo.configs/axis2
Re: [DISCUSS] URLClassloader problem
This problem is a real headache for us. We are deploying Axis2 in our web application on Geronimo. During development, we are currently reinstalling the server every time we want to deploy. I searched the Axis2 Jira, and I noticed that this is not currently listed as a problem. I was wondering if you plan to continue to try to resolve this. Also, do you know of an easier way to work around the problem? We really need one! -- View this message in context: http://www.nabble.com/-DISCUSS--URLClassloader-problem-tp19448428s134p1973.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] URLClassloader problem
On Sep 29, 2008, at 7:35 AM, jcaristi wrote: This problem is a real headache for us. We are deploying Axis2 in our web application on Geronimo. During development, we are currently reinstalling the server every time we want to deploy. I searched the Axis2 Jira, and I noticed that this is not currently listed as a problem. I was wondering if you plan to continue to try to resolve this. Also, do you know of an easier way to work around the problem? We really need one! Understood. Tim had mentioned to me that he was working on an Axis2 patch. I'm sure he'll let us know where he stands with this work. You could try removing the moduleId of your geronimo deployment plan. That should allow redeployment to at least work... The undeploy part will be slow (as it tries to delete the jar files), but deploy should create a new unique default/archive-name/random-number/war module. So, should at least work. Certainly, still a headache, will let you decide how it compares to your current *headache*. You'll eventually run out of PERMGEN space... Your repository directory will fill up with default/archive-name directories, also There's always the option of deploying your Axis2 libraries separately and declaring a dependency in your web app deployment plan... This should work perfectly (except your changing the contents of your WAR file, and not just defining a geronimo deployment plan). Hmm. Actually, could you leave your WAR contents unchanged and still use this technique? --kevan
[jira] Reopened: (GERONIMO-4230) When installing a plugin that is already existed, we still give people confusing missingDependency message
[ https://issues.apache.org/jira/browse/GERONIMO-4230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reopened GERONIMO-4230: --- As rev698248 is reverted and being reworked. When installing a plugin that is already existed, we still give people confusing missingDependency message -- Key: GERONIMO-4230 URL: https://issues.apache.org/jira/browse/GERONIMO-4230 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.2, 2.1.3, 2.2 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.2 For example, when I install the daytrader-streamer-client onto my server without knowing the module is already installed, the deployer gave me the following message: lin-suns-macbook-pro:bin linsun$ java install-plugin ~/daytrader/daytrader-tomcat/target/daytrader-streamer-client-2.2-SNAPSHOT.car Listening for transport dt_socket at address: 8011 Checking for status every 1000ms: Installation FAILED: Configuration org.apache.geronimo.daytrader/daytrader-streamer-client/2.2-SNAPSHOT/car is already installed. Missing dependency: org.apache.geronimo.daytrader/daytrader-streamer-client/2.2-SNAPSHOT/car The Missing Dependency message is rather confusing and should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4318) All the plugins are marked as installable on the install plugins portlet
[
https://issues.apache.org/jira/browse/GERONIMO-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635403#action_12635403
]
Lin Sun commented on GERONIMO-4318:
---
David,
I have tested the changes you made. Looks good on the portlets. There is a
minor issue with install .car file, when installing a .car file onto a server
that already has the plugin, as we don't notify the user that the plugin is
already existed. I am proposing the following change to fix that, hopefully
this would not interfere with your farming stuff. let me know.
Index:
framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
===
---
framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
(revision 699439)
+++
framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
(working copy)
@@ -932,7 +932,7 @@
// 2. Validate that we can install this
if (!validatePlugin(data)) {
//already installed
-return;
+throw new MissingDependencyException(Already installed,
toArtifact(data.getPluginArtifact().get(0).getModuleId()),
(StackArtifact)null);
}
Also, I'd like to replace the MissingDependencyException to
ConfigAlreadyExistException due to this JIRA - GERONIMO-4230. Any issue with
that?
Lin
All the plugins are marked as installable on the install plugins portlet
Key: GERONIMO-4318
URL: https://issues.apache.org/jira/browse/GERONIMO-4318
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.2
Reporter: Lin Sun
Assignee: Lin Sun
Fix For: 2.2
All the plugins are marked as installable on the install plugins portlet.
We check if a plugin is installable by using pluginInstaller.validatePlugin.
If an exception is thrown, then we set the installable to false. The throw
of MissingDependencyException in validatePlugin method is commented out
during rev 696105.
A proposed fix is to throw ConfigurationAlreadyExistsException when
validatePlugin fails because of the configuration is already installed.
This seems more reasonable and will also get rid of the confusion message of
Missing Dependency: XXX when a user attempts to install a plugin that has
already been installed using the deploy install-plugin command.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4318) All the plugins are marked as installable on the install plugins portlet
[ https://issues.apache.org/jira/browse/GERONIMO-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4318: -- Attachment: G4318.patch Sorry it was not formatted nicely in previous comment, so attaching a file here. All the plugins are marked as installable on the install plugins portlet Key: GERONIMO-4318 URL: https://issues.apache.org/jira/browse/GERONIMO-4318 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.2 Attachments: G4318.patch All the plugins are marked as installable on the install plugins portlet. We check if a plugin is installable by using pluginInstaller.validatePlugin. If an exception is thrown, then we set the installable to false. The throw of MissingDependencyException in validatePlugin method is commented out during rev 696105. A proposed fix is to throw ConfigurationAlreadyExistsException when validatePlugin fails because of the configuration is already installed. This seems more reasonable and will also get rid of the confusion message of Missing Dependency: XXX when a user attempts to install a plugin that has already been installed using the deploy install-plugin command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r699202 - in /geronimo/server/trunk: buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/ framework/modules/geronimo-deploy-jsr88/src/main/java/org/apache/
David,
I posted a comment to the JIRA (GERONIMO-4318), please review. Thanks
Lin
On Fri, Sep 26, 2008 at 2:07 PM, Lin Sun [EMAIL PROTECTED] wrote:
Cool - I am running a full build to check them out.
thanks
Lin
On Fri, Sep 26, 2008 at 1:26 PM, David Jencks [EMAIL PROTECTED] wrote:
On Sep 26, 2008, at 9:11 AM, David Jencks wrote:
On Sep 26, 2008, at 7:55 AM, Lin Sun wrote:
David, thanks for adding this to keep track of what plugins have been
installed on the server.
I think there is a prob with the change. In InstallModulesMojo.java,
as it set installedPluginsList as null. I think this would cause all
the plugins that came with the server assembly during build time
(using c-m-p) not recorded, as saveHistory and loadHistory only handle
cases when installedPluginList is not null.
I agree.
Also, in PluginInstallerGBean.java, I don't see anywhere you specify
where we set the default location of the installedPluginsList file to
var/config/installedPlugins.properties... I only see that in the
two test files.
I forgot to configure this in the plan.
I think I got these fixed in rev 699420. In my farm example the nodes seem
to be tracking what has been installed properly, and the c-m-p assembly
seems to be recording what was installed.
thanks again
david jencks
thanks for noticing these problems!
david jencks
Lin
On Fri, Sep 26, 2008 at 3:26 AM, [EMAIL PROTECTED] wrote:
Author: djencks
Date: Fri Sep 26 00:26:53 2008
New Revision: 699202
URL: http://svn.apache.org/viewvc?rev=699202view=rev
Log:
GERONIMO-4318 try to indicate when plugins have been installed in the
current server, irrespective of whether they are in the repos
Modified:
geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/InstallModulesMojo.java
geronimo/server/trunk/framework/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/jmx/RemoteDeploymentManager.java
geronimo/server/trunk/framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstaller.java
geronimo/server/trunk/framework/modules/geronimo-plugin/src/main/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
geronimo/server/trunk/framework/modules/geronimo-plugin/src/test/java/org/apache/geronimo/system/plugin/CopyFileTest.java
geronimo/server/trunk/framework/modules/geronimo-plugin/src/test/java/org/apache/geronimo/system/plugin/PluginInstallerTest.java
geronimo/server/trunk/plugins/console/plugin-portlets/src/main/java/org/apache/geronimo/console/car/AbstractListHandler.java
geronimo/server/trunk/plugins/console/plugin-portlets/src/main/java/org/apache/geronimo/console/car/ViewPluginDownloadHandler.java
Modified:
geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/InstallModulesMojo.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/InstallModulesMojo.java?rev=699202r1=699201r2=699202view=diff
==
---
geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/InstallModulesMojo.java
(original)
+++
geronimo/server/trunk/buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/InstallModulesMojo.java
Fri Sep 26 00:26:53 2008
@@ -162,7 +162,7 @@
Kernel kernel = new BasicKernel(Assembly);
PluginRepositoryList pluginRepoList = new
PluginRepositoryDownloader(Collections.singletonMap(localRepo, (String[])
null), true);
try {
-PluginInstallerGBean installer = new
PluginInstallerGBean(targetRepositoryPath, targetServerPath, servers,
pluginRepoList, kernel, getClass().getClassLoader());
+PluginInstallerGBean installer = new
PluginInstallerGBean(targetRepositoryPath, targetServerPath, null,
servers,
pluginRepoList, kernel, getClass().getClassLoader());
installer.install(pluginList, sourceRepo, true, null, null,
downloadPoller);
if (overrides != null) {
for (Override override: this.overrides) {
Modified:
geronimo/server/trunk/framework/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/jmx/RemoteDeploymentManager.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/jmx/RemoteDeploymentManager.java?rev=699202r1=699201r2=699202view=diff
==
---
geronimo/server/trunk/framework/modules/geronimo-deploy-jsr88/src/main/java/org/apache/geronimo/deployment/plugin/jmx/RemoteDeploymentManager.java
(original)
+++
boilerplate, jaxws-tools (convert from jar to car format?)
Hi, I'd like to convert all jar format geronimo plugins to car format, and currently I see boilerplate and jaxws-tools as jar format. When they are in jar format, they are marked as installable even if they are already installed. I think this is caused by the fact the c-m-p handles geronimo plugins in jar format and car format differently. I am hoping the converting is possible now that David puts support of no plan in c-m-p recently to avoid adding to the classloader and server config.Any reason why they are in jar format right now? Thanks Lin
Re: boilerplate, jaxws-tools (convert from jar to car format?)
On Sep 29, 2008, at 10:07 AM, Lin Sun wrote: Hi, I'd like to convert all jar format geronimo plugins to car format, and currently I see boilerplate and jaxws-tools as jar format. When they are in jar format, they are marked as installable even if they are already installed. I think this is caused by the fact the c-m-p handles geronimo plugins in jar format and car format differently. I am hoping the converting is possible now that David puts support of no plan in c-m-p recently to avoid adding to the classloader and server config.Any reason why they are in jar format right now? At least the boilerplate uses the assembly plugin rather than c-m-p. I'm not sure you will be able to get the assembly plugin to generate a .car file without switching to using the c-m-p. I think it would be nice to use c-m-p instead of the assembly plugin here but I'm not sure what you'd need to do. You might need to use the deployment plugin to copy a bunch of jars (j2ee-system-2.2-SNAPSHOT.car) to a temp area and the antrun plugin to copy them to the appropriate (e.g. bin/ server.jar) location. I tried out some stuff like this in rev http://svn.apache.org/viewcvs?view=revrev=697437 related to GERONIMO-4302: that had some other problems that caused me to revert the change. I hope you can get this to work one way or another without too much hair-pulling :-) thanks david jencks Thanks Lin
GShell Update
As some of you might have noticed I've been very busy for the past days working on GShell. I've been meaning to stop hacking and write some email about what I'm doing, but I always end up jumping into some feature or fixing some bug. But a lot has changed, so I really need to post some details... but rather than go all gooey on the details I am just going to point out the major changes. If anyone wants the gooey stuff, ping me back and I can explain in much more detail. CONTAINER Spring is used for 99% of the container needs. Still have some plexus stuff around to support maven-artifact-based resolution. Dropped gshell-rapture, too much work to keep the plexus glue up to date with the spring glue (aka gshell-wisdom). Layouts are gone, currently there is only a flat namespace for files... that is one of the major things left to be resolved. Originally I had though of the commands namespace like it was a filesystem, and you might even cd to change the path or whatever, but the VFS work (see below) really showed me that was not a good idea. I am planning on implementing a command namespace, just still trying to figure out how. More to come on this later I'm sure. The gshell-remote gshell-whisper stuff is now all spring happy, though it still needs to be re-implemented to move more of the configuration stuff into the spring context. There are still a lot of holes in this stuff, as I only have been making what was there before work again. So that is another major area which I plan to work on once the framework issues are sorted. I18N I've hooked up resource bundles for each and every command, and updated the CLP stuff to use them for messages related to --help content. Still need to hook up a really simple way to use i18n messages for all user output (except logging messages). But its getting closer. Related is that commands now have a manual, so if you say help help it will show you the manual for the help command, this text is also externalized for i18n, though I've not had time to write a manual for anything so they are all todo's right now. Once things stabilize more we can write those. VFS Implemented a bunch more VFS commands to operate on files: cd Changes the current directory. pwd Displays the current directory. ls List the contents of a file or directory. cp Copies a file or directory. rm Remove a file or directory. cat Displays the contents of a file. editEdit a file with an external editor. touch Sets the last-modified time of a file. dir Link to: ls copyLink to: cp del Link to: rm Changed all (well most, pending a commit for the script command to use this soon) commands to use VFS FileObjects instead of a File/URL, so they can take advantage of this flexibility. I think this stuff is really cool, and will really be helpful for real- users down the line. For example, with the VFS SFTP provider configured you can do something like: gshell cd sftp://myusername:[EMAIL PROTECTED]/pub gshell ls foo.txt bar.txt baz/ gshell cat foo.txt The cat will show whatever the contents are of foo.txt as you might expect. You can also copy files between filesystems, this would copy from the cwd (which is still what is set from above) to your local /tmp directory: gshell cp foo.txt /tmp And see that its there with: gshell ls /tmp/foo.txt Or if you just want to *edit* the contents of the remote file: gshell edit foo.txt This will open up an external editor with the contents of foo.txt, you can edit, save, close, then the changes are pushed to the remove. Same works for locals, minus the pull and push of content. Should work on windows, though I've not actually tried it to see what breaks. Some features left to be done, are implementing a virtual VFS thingy, so you can mount/unmount filesystems to get an aggregate view which you can easily cd around without needing horrible long URIs. COMPLETION Finally implemented completion. Commands that take files, alias names, variables names, etc now support tab-completion. Can even complete VFS paths! ALIASES LINKS Added support for command aliases (via alias foo bar and unalias foo) as well as linked commands (sorta aliases, but with better completion support). Aliases don't show up in 'help' output, they show up under 'alias' output, like how it works on a unix shell. Though please note, that the definition syntax does not include a = as the syntax parser is still too stupid to handle that well. Aliases don't have completer, as you can put any string as the value of the alias, so its really hard to figure out what command to resolve to and how to apply a completer for it. But I also wanted to provide some way to provide a different name for a command, so I
maven release process and samples
I've been trying to use the maven release process for samples.
The dryrun works fine and I've corrected all differences in the poms
beyond the version and scm entries. However, when I attempt the
release:prepare I hit the error below.
customer-ejb has already been processed but the jar only exists in the
customer-ejb target (and not in my local maven repo). In fact, none of
the already processed artifacts exist in my local maven repo at the time
of the failure ... just in the local target directories for each artifact.
Any ideas what might be going wrong and how to fix it? My guess is a
scope of provided might help but that doesn't seem to make logical sense
as we want the ear to include the ejb jar.
BTW, this all builds and deploys fine for regular builds.
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: customer-war-2.1.2.war
[INFO] Checking legal files in: customer-war-2.1.2-sources.jar
[INFO] Checking legal files in: customer-war-2.1.2-javadoc.jar
[INFO]
[INFO] Building Geronimo Samples :: customer :: EAR
[INFO]task-segment: [clean, verify]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/classes
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/test-classes
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/site
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb
-Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the
file there:
mvn deploy:deploy-file
-DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb
-Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file -Durl=[url]
-DrepositoryId=[id]
Path to dependency:
1) org.apache.geronimo.samples:customer-ear:ear:2.1.2
2) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
--
1 required artifact is missing.
for artifact:
org.apache.geronimo.samples:customer-ear:ear:2.1.2
from the specified remote repositories:
ibiblio.org (http://repo1.maven.org/maven2),
apache.snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
codehaus-snapshots (http://snapshots.repository.codehaus.org),
apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
[jira] Closed: (GERONIMO-4225) Allow Run SQL portlet run sql against any configured data source
[ https://issues.apache.org/jira/browse/GERONIMO-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-4225. -- Resolution: Fixed patch applied to branches/2.1 and trunk Michal, thanks for the patch. Allow Run SQL portlet run sql against any configured data source Key: GERONIMO-4225 URL: https://issues.apache.org/jira/browse/GERONIMO-4225 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: databases Affects Versions: 2.1.1 Reporter: Michal Borowiecki Assignee: Donald Woods Priority: Minor Fix For: 2.1.4, 2.2 Attachments: sysdb-portlets-2.1.1.patch, sysdb-portlets-trunk.patch Currently Run SQL portlet allows only running queries against internal Derby databases. It would be very useful if it allowed to run SQL against any of the datasources configured. Create DB and Delete DB features are Derby specific, Use DB on the other hand can be easily generalized to use any data source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: maven release process and samples
Um... do you see any [install:install] goals being run?
My guess is that the preparation goals are set to clean verify or
something, and should be clean install.
--jason
On Sep 30, 2008, at 1:07 AM, Joe Bohn wrote:
I've been trying to use the maven release process for samples.
The dryrun works fine and I've corrected all differences in the poms
beyond the version and scm entries. However, when I attempt the
release:prepare I hit the error below.
customer-ejb has already been processed but the jar only exists in
the customer-ejb target (and not in my local maven repo). In fact,
none of the already processed artifacts exist in my local maven repo
at the time of the failure ... just in the local target directories
for each artifact.
Any ideas what might be going wrong and how to fix it? My guess is
a scope of provided might help but that doesn't seem to make logical
sense as we want the ear to include the ejb jar.
BTW, this all builds and deploys fine for regular builds.
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: customer-war-2.1.2.war
[INFO] Checking legal files in: customer-war-2.1.2-sources.jar
[INFO] Checking legal files in: customer-war-2.1.2-javadoc.jar
[INFO]
[INFO] Building Geronimo Samples :: customer :: EAR
[INFO]task-segment: [clean, verify]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /Users/bohn/geronimo-samples-2.1/
samples/customer/customer-ear/target
[INFO] Deleting directory /Users/bohn/geronimo-samples-2.1/
samples/customer/customer-ear/target/classes
[INFO] Deleting directory /Users/bohn/geronimo-samples-2.1/
samples/customer/customer-ear/target/test-classes
[INFO] Deleting directory /Users/bohn/geronimo-samples-2.1/
samples/customer/customer-ear/target/site
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -
DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb -
Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy
the file there:
mvn deploy:deploy-file -
DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb -
Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file -Durl=[url] -
DrepositoryId=[id]
Path to dependency:
1) org.apache.geronimo.samples:customer-ear:ear:2.1.2
2) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
--
1 required artifact is missing.
for artifact:
org.apache.geronimo.samples:customer-ear:ear:2.1.2
from the specified remote repositories:
ibiblio.org (http://repo1.maven.org/maven2),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository
),
apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository
),
codehaus-snapshots (http://
snapshots.repository.codehaus.org),
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/
)
Re: GShell Update
Oh, I also forgot one thing. I registered the gshell.org domain and set it up to redirect to http://geronimo.apache.org/gshell automatically. I also fixed the redirects in the site content, so actually http://geronimo.apache.org/gshell will redirect you to http://cwiki.apache.org/GSHELL. The other redirects in the Support sidenav in the GSHELL space have also been updated to work. --jason On Tue, Sep 30, 2008 at 1:02 AM, Jason Dillon [EMAIL PROTECTED] wrote: As some of you might have noticed I've been very busy for the past days working on GShell. I've been meaning to stop hacking and write some email about what I'm doing, but I always end up jumping into some feature or fixing some bug. But a lot has changed, so I really need to post some details... but rather than go all gooey on the details I am just going to point out the major changes. If anyone wants the gooey stuff, ping me back and I can explain in much more detail. CONTAINER Spring is used for 99% of the container needs. Still have some plexus stuff around to support maven-artifact-based resolution. Dropped gshell-rapture, too much work to keep the plexus glue up to date with the spring glue (aka gshell-wisdom). Layouts are gone, currently there is only a flat namespace for files... that is one of the major things left to be resolved. Originally I had though of the commands namespace like it was a filesystem, and you might even cd to change the path or whatever, but the VFS work (see below) really showed me that was not a good idea. I am planning on implementing a command namespace, just still trying to figure out how. More to come on this later I'm sure. The gshell-remote gshell-whisper stuff is now all spring happy, though it still needs to be re-implemented to move more of the configuration stuff into the spring context. There are still a lot of holes in this stuff, as I only have been making what was there before work again. So that is another major area which I plan to work on once the framework issues are sorted. I18N I've hooked up resource bundles for each and every command, and updated the CLP stuff to use them for messages related to --help content. Still need to hook up a really simple way to use i18n messages for all user output (except logging messages). But its getting closer. Related is that commands now have a manual, so if you say help help it will show you the manual for the help command, this text is also externalized for i18n, though I've not had time to write a manual for anything so they are all todo's right now. Once things stabilize more we can write those. VFS Implemented a bunch more VFS commands to operate on files: cd Changes the current directory. pwd Displays the current directory. ls List the contents of a file or directory. cp Copies a file or directory. rm Remove a file or directory. cat Displays the contents of a file. editEdit a file with an external editor. touch Sets the last-modified time of a file. dir Link to: ls copyLink to: cp del Link to: rm Changed all (well most, pending a commit for the script command to use this soon) commands to use VFS FileObjects instead of a File/URL, so they can take advantage of this flexibility. I think this stuff is really cool, and will really be helpful for real-users down the line. For example, with the VFS SFTP provider configured you can do something like: gshell cd sftp://myusername:[EMAIL PROTECTED]/pub gshell ls foo.txt bar.txt baz/ gshell cat foo.txt The cat will show whatever the contents are of foo.txt as you might expect. You can also copy files between filesystems, this would copy from the cwd (which is still what is set from above) to your local /tmp directory: gshell cp foo.txt /tmp And see that its there with: gshell ls /tmp/foo.txt Or if you just want to *edit* the contents of the remote file: gshell edit foo.txt This will open up an external editor with the contents of foo.txt, you can edit, save, close, then the changes are pushed to the remove. Same works for locals, minus the pull and push of content. Should work on windows, though I've not actually tried it to see what breaks. Some features left to be done, are implementing a virtual VFS thingy, so you can mount/unmount filesystems to get an aggregate view which you can easily cd around without needing horrible long URIs. COMPLETION Finally implemented completion. Commands that take files, alias names, variables names, etc now support tab-completion. Can even complete VFS paths! ALIASES LINKS Added support for command aliases (via alias foo bar and unalias foo) as well as linked commands (sorta aliases, but with better completion support). Aliases don't show up in 'help' output, they show up under 'alias' output, like how it works
Re: maven release process and samples
Nope, there are no install:install goals being run.
Joe
Jason Dillon wrote:
Um... do you see any [install:install] goals being run?
My guess is that the preparation goals are set to clean verify or
something, and should be clean install.
--jason
On Sep 30, 2008, at 1:07 AM, Joe Bohn wrote:
I've been trying to use the maven release process for samples.
The dryrun works fine and I've corrected all differences in the poms
beyond the version and scm entries. However, when I attempt the
release:prepare I hit the error below.
customer-ejb has already been processed but the jar only exists in the
customer-ejb target (and not in my local maven repo). In fact, none
of the already processed artifacts exist in my local maven repo at the
time of the failure ... just in the local target directories for each
artifact.
Any ideas what might be going wrong and how to fix it? My guess is a
scope of provided might help but that doesn't seem to make logical
sense as we want the ear to include the ejb jar.
BTW, this all builds and deploys fine for regular builds.
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: customer-war-2.1.2.war
[INFO] Checking legal files in: customer-war-2.1.2-sources.jar
[INFO] Checking legal files in: customer-war-2.1.2-javadoc.jar
[INFO]
[INFO] Building Geronimo Samples :: customer :: EAR
[INFO]task-segment: [clean, verify]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/classes
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/test-classes
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/site
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb
-Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the
file there:
mvn deploy:deploy-file
-DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb
-Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file -Durl=[url]
-DrepositoryId=[id]
Path to dependency:
1) org.apache.geronimo.samples:customer-ear:ear:2.1.2
2) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
--
1 required artifact is missing.
for artifact:
org.apache.geronimo.samples:customer-ear:ear:2.1.2
from the specified remote repositories:
ibiblio.org (http://repo1.maven.org/maven2),
apache.snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
codehaus-snapshots (http://snapshots.repository.codehaus.org),
apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
[jira] Commented: (GERONIMO-4081) Accessibility issue: Webking scan errors against Check Web Accessibility(Section 508) rules
[ https://issues.apache.org/jira/browse/GERONIMO-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635470#action_12635470 ] Donald Woods commented on GERONIMO-4081: Applied Plancreator-4081.patch to trunk as Rev700197 Accessibility issue: Webking scan errors against Check Web Accessibility(Section 508) rules - Key: GERONIMO-4081 URL: https://issues.apache.org/jira/browse/GERONIMO-4081 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.1, 2.1.2, 2.2 Environment: Windows XP SP2, IE 6.0 Webking 5.5 Reporter: Forrest Xia Assignee: Donald Woods Fix For: 2.2 Attachments: GERONIMO-4081-activemq.patch, GERONIMO-4081-ca-helper.patch, GERONIMO-4081-console.patch, GERONIMO-4081-debugviews.patch, GERONIMO-4081-monitoring.patch, GERONIMO-4081-plancreator.patch, GERONIMO-4081-system-database.patch, GERONIMO-4081-welcome.patch, Plancreator-4081.patch, screenshot-1.jpg, webking_scan_results.csv, webking_scan_results_src.csv Lots of instances are violated from the accessibility rules of section 508, see the attachment for details. thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4081) Accessibility issue: Webking scan errors against Check Web Accessibility(Section 508) rules
[ https://issues.apache.org/jira/browse/GERONIMO-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-4081. Resolution: Fixed Last expected patch has been applied. Ivan, if additional problems are found before 2.2 is released, please open new JIRAs and assign to me. Also, can you add a page to the Dev wiki (GMOxDEV) about the Webking tests and how to avoid these problems in the future? Accessibility issue: Webking scan errors against Check Web Accessibility(Section 508) rules - Key: GERONIMO-4081 URL: https://issues.apache.org/jira/browse/GERONIMO-4081 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.1, 2.1.2, 2.2 Environment: Windows XP SP2, IE 6.0 Webking 5.5 Reporter: Forrest Xia Assignee: Donald Woods Fix For: 2.2 Attachments: GERONIMO-4081-activemq.patch, GERONIMO-4081-ca-helper.patch, GERONIMO-4081-console.patch, GERONIMO-4081-debugviews.patch, GERONIMO-4081-monitoring.patch, GERONIMO-4081-plancreator.patch, GERONIMO-4081-system-database.patch, GERONIMO-4081-welcome.patch, Plancreator-4081.patch, screenshot-1.jpg, webking_scan_results.csv, webking_scan_results_src.csv Lots of instances are violated from the accessibility rules of section 508, see the attachment for details. thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: maven release process and samples
Actually, I wonder why it would need to do anything beyond perhaps
validate if the primary task is to update svn with the new tag and versions.
Joe
Joe Bohn wrote:
Nope, there are no install:install goals being run.
Joe
Jason Dillon wrote:
Um... do you see any [install:install] goals being run?
My guess is that the preparation goals are set to clean verify or
something, and should be clean install.
--jason
On Sep 30, 2008, at 1:07 AM, Joe Bohn wrote:
I've been trying to use the maven release process for samples.
The dryrun works fine and I've corrected all differences in the poms
beyond the version and scm entries. However, when I attempt the
release:prepare I hit the error below.
customer-ejb has already been processed but the jar only exists in
the customer-ejb target (and not in my local maven repo). In fact,
none of the already processed artifacts exist in my local maven repo
at the time of the failure ... just in the local target directories
for each artifact.
Any ideas what might be going wrong and how to fix it? My guess is a
scope of provided might help but that doesn't seem to make logical
sense as we want the ear to include the ejb jar.
BTW, this all builds and deploys fine for regular builds.
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: customer-war-2.1.2.war
[INFO] Checking legal files in: customer-war-2.1.2-sources.jar
[INFO] Checking legal files in: customer-war-2.1.2-javadoc.jar
[INFO]
[INFO] Building Geronimo Samples :: customer :: EAR
[INFO]task-segment: [clean, verify]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/classes
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/test-classes
[INFO] Deleting directory
/Users/bohn/geronimo-samples-2.1/samples/customer/customer-ear/target/site
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb
-Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy
the file there:
mvn deploy:deploy-file
-DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb
-Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file -Durl=[url]
-DrepositoryId=[id]
Path to dependency:
1) org.apache.geronimo.samples:customer-ear:ear:2.1.2
2) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
--
1 required artifact is missing.
for artifact:
org.apache.geronimo.samples:customer-ear:ear:2.1.2
from the specified remote repositories:
ibiblio.org (http://repo1.maven.org/maven2),
apache.snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
codehaus-snapshots (http://snapshots.repository.codehaus.org),
apache-incubator
(http://people.apache.org/repo/m2-incubating-repository/)
Re: maven release process and samples
I'm not sure, can you re-run with -X and see what its doing?
--jason
On Sep 30, 2008, at 1:30 AM, Joe Bohn wrote:
Actually, I wonder why it would need to do anything beyond perhaps
validate if the primary task is to update svn with the new tag and
versions.
Joe
Joe Bohn wrote:
Nope, there are no install:install goals being run.
Joe
Jason Dillon wrote:
Um... do you see any [install:install] goals being run?
My guess is that the preparation goals are set to clean verify or
something, and should be clean install.
--jason
On Sep 30, 2008, at 1:07 AM, Joe Bohn wrote:
I've been trying to use the maven release process for samples.
The dryrun works fine and I've corrected all differences in the
poms beyond the version and scm entries. However, when I attempt
the release:prepare I hit the error below.
customer-ejb has already been processed but the jar only exists
in the customer-ejb target (and not in my local maven repo). In
fact, none of the already processed artifacts exist in my local
maven repo at the time of the failure ... just in the local
target directories for each artifact.
Any ideas what might be going wrong and how to fix it? My guess
is a scope of provided might help but that doesn't seem to make
logical sense as we want the ear to include the ejb jar.
BTW, this all builds and deploys fine for regular builds.
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: customer-war-2.1.2.war
[INFO] Checking legal files in: customer-war-2.1.2-
sources.jar
[INFO] Checking legal files in: customer-war-2.1.2-
javadoc.jar
[INFO]
[INFO] Building Geronimo Samples :: customer :: EAR
[INFO]task-segment: [clean, verify]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /Users/bohn/geronimo-samples-2.1/
samples/customer/customer-ear/target
[INFO] Deleting directory /Users/bohn/geronimo-samples-2.1/
samples/customer/customer-ear/target/classes
[INFO] Deleting directory /Users/bohn/geronimo-samples-2.1/
samples/customer/customer-ear/target/test-classes
[INFO] Deleting directory /Users/bohn/geronimo-samples-2.1/
samples/customer/customer-ear/target/site
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/samples/customer-ejb/2.1.2/customer-ejb-2.1.2.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -
DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb -
Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy
the file there:
mvn deploy:deploy-file -
DgroupId=org.apache.geronimo.samples -DartifactId=customer-ejb -
Dversion=2.1.2 -Dpackaging=ejb -Dfile=/path/to/file -Durl=[url] -
DrepositoryId=[id]
Path to dependency:
1) org.apache.geronimo.samples:customer-ear:ear:2.1.2
2) org.apache.geronimo.samples:customer-ejb:ejb:2.1.2
--
1 required artifact is missing.
for artifact:
org.apache.geronimo.samples:customer-ear:ear:2.1.2
from the specified remote repositories:
ibiblio.org (http://repo1.maven.org/maven2),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository
),
apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository
),
codehaus-snapshots (http://snapshots.repository.codehaus.org
),
apache-incubator (http://people.apache.org/repo/m2-incubating-repository/
)
[jira] Created: (GERONIMO-4326) Update Repository List action in Plugins portlet is broken
Update Repository List action in Plugins portlet is broken
--
Key: GERONIMO-4326
URL: https://issues.apache.org/jira/browse/GERONIMO-4326
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: Plugins
Affects Versions: 2.2
Reporter: Donald Woods
Priority: Critical
Fix For: 2.2
Seems that some of the recent changes to Plugins has broken this.
Maybe the fact that what used to be a userRepositories attribute on the GBean
is now userRepositoryList pointing to
var/config/plugin-repositories.properties
{noformat}
14:32:12,635 ERROR [PluginRepositoryDownloader] Unable to save download
repositories
java.lang.IllegalStateException: This persistent attribute is not modifable
while the gbean is running. Attribute Name: downloadRepositories, Type:
interface java.util.List, GBeanInstance: PluginRepositoryDownloader
at
org.apache.geronimo.gbean.runtime.GBeanAttribute.setValue(GBeanAttribute.java:352)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:745)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:730)
at
org.apache.geronimo.kernel.basic.BasicKernel.setAttribute(BasicKernel.java:194)
at
org.apache.geronimo.system.plugin.PluginRepositoryDownloader.refresh(PluginRepositoryDownloader.java:259)
at
org.apache.geronimo.console.car.UpdateListHandler.actionBeforeView(UpdateListHandler.java:46)
at
org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:112)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472)
at
org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)
at
org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85)
at
org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219)
at
org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:613)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Inverse Classloading versus Hidden Class, was Re: Issues running Tuscany applications in Geronimo 2.1.3
Hi Kevan Your suggestion on TUSCANY-2622 is to stop using the inverse class loading, and start to list some of the dependencies in the hidden class section of the geronimo deployment descriptor. Although it allows me to make progress with some of my tests, I was wondering what has caused the inverse classloading configuration to stop working. On Sun, Sep 28, 2008 at 11:02 PM, Luciano Resende [EMAIL PROTECTED] wrote: Thanks. that solved the problem !!! On Sun, Sep 28, 2008 at 6:49 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Sep 26, 2008, at 3:47 AM, Luciano Resende wrote: I'm trying to bringup a Tuscany application in Geronimo 2.1.3, and after fixing some TLD issues and JAXB dependency conflict issues, I still can't successfully start my Tuscany application (e.g calculator-ws-webapp) and the logs are showing the following classCastException. Any ideas and possible workarounds ? Luciano, I've created TUSCANY-2622 (https://issues.apache.org/jira/browse/TUSCANY-2622) and attached a patch to the geronimo-web.xml deployment plan being used by the alert-aggregator-webapp. The patch removes inverse-classloading and uses hidden-classes filters, instead. I ran tests with the updated deployment plan, and things seemed to work pretty well for me. --kevan -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: boilerplate, jaxws-tools (convert from jar to car format?)
I tried to change boilerplate to car format and it seems okay (the assembly plugin is able to generate a .car file). However, my other problem still remains that the boilerplate and jaxws-tools still shows as installable when I request to display plugins listed at http://localhost:8080/plugin/maven-repo/, along with those plugin groups. For plugin groups, I can add some logic in validatePlugin method in plugininstaller to handle plugin groups... but not sure how to handle these two? They are essentially same as plugin groups that we cannot uninstall them and should be marked as not installable if they are listed in the installed-plugins list IMHO. Maybe we need to introduce another property in plugin metadata to differentiate them? or always put them into a particular category? Lin On Mon, Sep 29, 2008 at 1:50 PM, David Jencks [EMAIL PROTECTED] wrote: At least the boilerplate uses the assembly plugin rather than c-m-p. I'm not sure you will be able to get the assembly plugin to generate a .car file without switching to using the c-m-p. I think it would be nice to use c-m-p instead of the assembly plugin here but I'm not sure what you'd need to do. You might need to use the deployment plugin to copy a bunch of jars (j2ee-system-2.2-SNAPSHOT.car) to a temp area and the antrun plugin to copy them to the appropriate (e.g. bin/server.jar) location. I tried out some stuff like this in rev http://svn.apache.org/viewcvs?view=revrev=697437 related to GERONIMO-4302: that had some other problems that caused me to revert the change. I hope you can get this to work one way or another without too much hair-pulling :-) thanks david jencks Thanks Lin
Re: GShell Update
Jason, Please send an courtesy heads up email to infrastructure@ when you get a chance. thanks, dims On Mon, Sep 29, 2008 at 2:18 PM, Jason Dillon [EMAIL PROTECTED] wrote: Oh, I also forgot one thing. I registered the gshell.org domain and set it up to redirect to http://geronimo.apache.org/gshell automatically. I also fixed the redirects in the site content, so actually http://geronimo.apache.org/gshell will redirect you to http://cwiki.apache.org/GSHELL. The other redirects in the Support sidenav in the GSHELL space have also been updated to work. --jason On Tue, Sep 30, 2008 at 1:02 AM, Jason Dillon [EMAIL PROTECTED] wrote: As some of you might have noticed I've been very busy for the past days working on GShell. I've been meaning to stop hacking and write some email about what I'm doing, but I always end up jumping into some feature or fixing some bug. But a lot has changed, so I really need to post some details... but rather than go all gooey on the details I am just going to point out the major changes. If anyone wants the gooey stuff, ping me back and I can explain in much more detail. CONTAINER Spring is used for 99% of the container needs. Still have some plexus stuff around to support maven-artifact-based resolution. Dropped gshell-rapture, too much work to keep the plexus glue up to date with the spring glue (aka gshell-wisdom). Layouts are gone, currently there is only a flat namespace for files... that is one of the major things left to be resolved. Originally I had though of the commands namespace like it was a filesystem, and you might even cd to change the path or whatever, but the VFS work (see below) really showed me that was not a good idea. I am planning on implementing a command namespace, just still trying to figure out how. More to come on this later I'm sure. The gshell-remote gshell-whisper stuff is now all spring happy, though it still needs to be re-implemented to move more of the configuration stuff into the spring context. There are still a lot of holes in this stuff, as I only have been making what was there before work again. So that is another major area which I plan to work on once the framework issues are sorted. I18N I've hooked up resource bundles for each and every command, and updated the CLP stuff to use them for messages related to --help content. Still need to hook up a really simple way to use i18n messages for all user output (except logging messages). But its getting closer. Related is that commands now have a manual, so if you say help help it will show you the manual for the help command, this text is also externalized for i18n, though I've not had time to write a manual for anything so they are all todo's right now. Once things stabilize more we can write those. VFS Implemented a bunch more VFS commands to operate on files: cd Changes the current directory. pwd Displays the current directory. ls List the contents of a file or directory. cp Copies a file or directory. rm Remove a file or directory. cat Displays the contents of a file. editEdit a file with an external editor. touch Sets the last-modified time of a file. dir Link to: ls copyLink to: cp del Link to: rm Changed all (well most, pending a commit for the script command to use this soon) commands to use VFS FileObjects instead of a File/URL, so they can take advantage of this flexibility. I think this stuff is really cool, and will really be helpful for real-users down the line. For example, with the VFS SFTP provider configured you can do something like: gshell cd sftp://myusername:[EMAIL PROTECTED]/pub gshell ls foo.txt bar.txt baz/ gshell cat foo.txt The cat will show whatever the contents are of foo.txt as you might expect. You can also copy files between filesystems, this would copy from the cwd (which is still what is set from above) to your local /tmp directory: gshell cp foo.txt /tmp And see that its there with: gshell ls /tmp/foo.txt Or if you just want to *edit* the contents of the remote file: gshell edit foo.txt This will open up an external editor with the contents of foo.txt, you can edit, save, close, then the changes are pushed to the remove. Same works for locals, minus the pull and push of content. Should work on windows, though I've not actually tried it to see what breaks. Some features left to be done, are implementing a virtual VFS thingy, so you can mount/unmount filesystems to get an aggregate view which you can easily cd around without needing horrible long URIs. COMPLETION Finally implemented completion. Commands that take files, alias names, variables names, etc now support tab-completion. Can even complete VFS paths! ALIASES LINKS Added support for command aliases (via alias foo bar and
[jira] Resolved: (GERONIMODEVTOOLS-379) unable to set cmp-connection-factory
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed resolved GERONIMODEVTOOLS-379. Resolution: Fixed Fixed with revision 700249. Added a new OpenEjbJarCMPSection.java that is used by the EjbOverviewPage to update the proper JAXB objects. unable to set cmp-connection-factory Key: GERONIMODEVTOOLS-379 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-379 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.3 Reporter: B.J. Reed Assignee: B.J. Reed Priority: Minor Fix For: 2.2.0 -- 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: 700213
Geronimo Revision: 700213 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 31 seconds
[INFO] Finished at: Mon Sep 29 15:42:40 EDT 2008
[INFO] Final Memory: 375M/1014M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929/logs-1500-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.framework:geronimo-deploy-jsr88:2.2-SNAPSHOT: checking for
updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.framework:geronimo-deploy-jsr88:2.2-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:40.684
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:08.800)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:28.898)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:17.894)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:16.046)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:13.397)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:26.532) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:42.981)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:45.286)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:01:02.054)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:43.998)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:29.846)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.297)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:28.977)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:41.236)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:47.722)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:49.891)
[INFO] enterprise-testsuite/sec-client RUNNING
Re: Client/Server Multicast Discovery and Failover
Checked in a small test app that allows this stuff to be taken for a spin. http://svn.apache.org/repos/asf/geronimo/sandbox/failover/ Hopefully we can use it as a tool to start getting some feedback. Some of the parts of it are getting reworked, but should be runnable soon. -David On Sep 12, 2008, at 5:43 PM, David Blevins wrote: I've added some functionality to OpenEJB trunk which has been enabled in Geronimo trunk. Here's an overview of how it works: DISCOVERY What we have going on from a tech perspective is each server sends and receives a multicast heartbeat. Each multicast packet contains a single URI that advertises a service, its group, and its location. Say for example cluster1:ejb:ejbd://thehost:4201. We can definitely explore the SLP format as Alan suggests. There are other advantages of the simple, unchanging, URI style. The URI is essentially stateless as there is no i'm alive URI or an i'm dead URI, there is simply a URI for each service a server offers and its presence on the network indicates its availability and its absence indicates the service is no longer available. In this way the issues with UDP being unordered and unreliable melt away as state is no longer a concern and packet sizes are always small. Complicated libraries that ride atop UDP and attempt to offer reliability (retransmission) and ordering on UDP can be avoided. UDP/Multicast is only used for discovery and from there on out critical information is transmitted over TCP/IP which is obviously going to do a better job at ensuring reliability and ordering. On the client side of things, a special multicast:// URL can be used in the InitialContext properties to signify that multicast should be used to seed the connection process. Such as: Properties properties = new Properties(); properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, org.apache.openejb.client.RemoteInitialContextFactory); properties.setProperty(Context.PROVIDER_URL, multicast:// 239.255.2.3:6142); InitialContext remoteContext = new InitialContext(properties); The URL has optional query parameters such as schemes and group and timeout which allow you to zero in on a particular type of service of a particular cluster group as well as set how long you are willing to wait in the discovery process till finally giving up. The first matching service that it sees flowing around on the UDP stream is the one it picks and sticks to for that and subsequent requests, ensuring UDP is only used when there are no other servers to talk to. FAILOVER On each request the server, the client will send the version number associated with the list of servers in the cluster it is aware of. Initially this version will be zero and the list will be empty. Only when the server sees the client has an old list will the server send the updated list. This is an important distinction as the list (ClusterMetaData) is not transmitted back and forth on every request, only on change. If the membership of the cluster is stable there is essentially no clustering overhead to the protocol -- 8 byte overhead to each request and 1 byte on each response -- so you will *not* see an exponential slowdown in response times the more members are added to the cluster. This new list takes affect for all proxies that share the same ServerMetaData data. Internally we key the ClusterMetaData by ServerMetaData. I originally had the version be a simple increment by one strategy, but eventually went with the value of System.currentTimeMillis(). It's possible more than one server is reachable via the ServerMetaData (i.e. multicast://) and each server has it's own list and version number. Secondly, if a server is restarted, the version number will go back to zero and the client could be stuck thinking it has a more current list than the server. When a server shuts down, more connections are refused, existing connections not in mid-request are closed, any remaining connections are closed immediately after completion of the request in progress and clients can failover gracefully to the next server in the list. If a server crashes requests are retried on the next server in the list. This failover pattern is followed until there are no more servers in the list at which point the client attempts a final multicast search (if it was created with a multicast PROVIDER_URL) before abandoning the request and throwing an exception to the caller. Currently, the failover is ordered but could very easily be made random. The multicast discovery aspect of the client adds a nice randomness to the selection of the first server that is perhaps somewhat just. Theoretically, servers that are under more load will send out less heart beats than servers with no load. This may not happen as theory dictates, but certainly as we get more ejb statistic data wired
[VOTE] Release Geronimo Samples 2.1.2
All, I've prepared a release candidate of Geronimo Samples 2.1.2 for your review and vote. This is the first independent release of samples for Geronimo. All together, there are 86 deliverables included in the staging repository. There are many documentation updates necessary which can continue concurrent with (and subsequent to) the vote. The sample wiki documentation is located here: http://cwiki.apache.org/GMOxDOC21/sample-applications.html I'll say up-front that the samples are still far from perfect. However, I think they are all functional with a few warts. IMO we need to get these released. The samples can be installed on either a Geronimo 2.1.2 or Geronimo 2.1.3 server image. They should also work on 2.1.4-SNAPSHOT but I personally have not verified using the latest snapshot and that is not a target server. All of the samples are available for installation as plugins and I have created a temporary plugin catalog for your convenience (see directions below). Staging repo: http://people.apache.org/~jbohn/staging-repo/geronimo-samples/ Staging site: http://people.apache.org/~jbohn/staging-site/geronimo-samples/2.1.2/ The svn location is here: https://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.1.2 Repository for plugin install (same as staging repo): http://people.apache.org/~jbohn/staging-repo/geronimo-samples/ - From the console navigation to Plugins - select Add Repository - paste in my staging repo listed above: - click Add - Select the newly added repository from the drop down list - click Show Plugins in selected repository - You should see the samples plugins listed. When the release vote is approved, the maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache and the maven site will be published. The vote is open for 72 hours and will conclude on 10/02/2008 at 11:00 PM ET. [ ] +1 Release Geronimo Samples 2.1.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo Samples 2.1.2 (please provide rationale) Joe
[DISCUSS] Discussion thread for Geronimo Samples 2.1.2 vote
This a thread to discuss any issues as a result of the Geronimo Samples 2.1.2 vote candidate. Joe
[BUILD] trunk: Failed for Revision: 700319
Geronimo Revision: 700319 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 26 seconds
[INFO] Finished at: Mon Sep 29 21:43:56 EDT 2008
[INFO] Final Memory: 361M/1014M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080929/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.framework:geronimo-deploy-jsr88:2.2-SNAPSHOT: checking for
updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.framework:geronimo-deploy-jsr88:2.2-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:39.524
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:13.542)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.154)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:18.459)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:16.014)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:12.524)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:28.126) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:43.866)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:43.474)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:01:01.677)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:43.991)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:29.568)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.658)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:27.855)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:40.689)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:47.609)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:50.908)
[INFO] enterprise-testsuite/sec-client RUNNING
