Re: [BUILD] Trunk: Failed for Revision: 573778
I think I fixed this.
thanks
david jencks
On Sep 7, 2007, at 8:30 PM, [EMAIL PROTECTED] wrote:
OpenEJB trunk at 573775
Geronimo Revision: 573778 built with tests skipped
See the full build-2300.log file at http://people.apache.org/
~prasad/binaries/trunk/20070907/build-2300.log
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar: /home/prasad/geronimo/trunk/modules/geronimo-
myfaces-builder/target/geronimo-myfaces-builder-2.1-SNAPSHOT.jar
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-myfaces-builder-2.1-
SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/modules/geronimo-
myfaces-builder/target/geronimo-myfaces-builder-2.1-SNAPSHOT.jar
to /home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-
myfaces-builder/2.1-SNAPSHOT/geronimo-myfaces-builder-2.1-SNAPSHOT.jar
[INFO]
--
--
[INFO] Building Geronimo Maven2 Plugins
[INFO]task-segment: [install]
[INFO]
--
--
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/
maven-plugin-plugin/2.2/maven-plugin-plugin-2.2.pom
5K downloaded
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/
maven-plugin-plugin/2.2/maven-plugin-plugin-2.2.jar
17K downloaded
[INFO] Reloading plugin container for:
org.apache.maven.plugins:maven-plugin-plugin. The plugin artifact
has changed.
Downloading: http://download.java.net/maven/1//org.apache.maven/
jars/maven-project-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-
project:jar:2.0.4' from repository java.net (http://
download.java.net/maven/1/)
Downloading: http://people.apache.org/repo/m2-incubating-
repository//org/apache/maven/maven-project/2.0.4/maven-
project-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-
project:jar:2.0.4' from repository apache-incubator (http://
people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repository.codehaus.org/org/apache/maven/maven-
project/2.0.4/maven-project-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-
project:jar:2.0.4' from repository codehaus.org (http://
repository.codehaus.org)
Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
project/2.0.4/maven-project-2.0.4.jar
106K downloaded
Downloading: http://download.java.net/maven/1//org.apache.maven/
jars/maven-artifact-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-
artifact:jar:2.0.4' from repository java.net (http://
download.java.net/maven/1/)
Downloading: http://people.apache.org/repo/m2-incubating-
repository//org/apache/maven/maven-artifact/2.0.4/maven-
artifact-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-
artifact:jar:2.0.4' from repository apache-incubator (http://
people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repository.codehaus.org/org/apache/maven/maven-
artifact/2.0.4/maven-artifact-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-
artifact:jar:2.0.4' from repository codehaus.org (http://
repository.codehaus.org)
Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
artifact/2.0.4/maven-artifact-2.0.4.jar
78K downloaded
Downloading: http://download.java.net/maven/1//org.apache.maven/
jars/maven-repository-metadata-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-repository-
metadata:jar:2.0.4' from repository java.net (http://
download.java.net/maven/1/)
Downloading: http://people.apache.org/repo/m2-incubating-
repository//org/apache/maven/maven-repository-metadata/2.0.4/maven-
repository-metadata-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-repository-
metadata:jar:2.0.4' from repository apache-incubator (http://
people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-
repository-metadata/2.0.4/maven-repository-metadata-2.0.4.jar
19K downloaded
Downloading: http://download.java.net/maven/1//org.apache.maven/
jars/maven-plugin-api-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-plugin-
api:jar:2.0.4' from repository java.net (http://download.java.net/
maven/1/)
Downloading: http://people.apache.org/repo/m2-incubating-
repository//org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-
api-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-plugin-
api:jar:2.0.4' from repository apache-incubator (http://
people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repository.codehaus.org/org/apache/maven/maven-
plugin-api/2.0.4/maven-plugin-api-2.0.4.jar
[WARNING] Unable to get resource 'org.apache.maven:maven-plugin-
api:jar:2.0.4' from repository codehaus.org (http://
repository.codehaus.org)
Downloading:
Change in location of plan.xml files for configs.
I should have mentioned this on the dev list before making the change but along with a lot of changes to how plans are processed by the car- maven-plugin I moved the location of the source plan to src/main/plan/plan.xml from src/plan/plan.xml If you want more or less the same behavior of using the maven dependencies for the geronimo dependencies you should include useMavenDependencies valuetrue/value includeVersiontrue/includeVersion /useMavenDependencies in your car-maven-plugin configuration. Othewise you can list the dependencies with exactly the importType and version you want in the car-maven-plugin configuration. There are some it tests in the car- maven-plugin with some simple examples. They also show a bit about how to generate reasonable geronimo-plugin.xmls. Most of the configs are not yet converted to really use the new c-m-p features so I've left the old plans in the old location until its clear nothing is broken. thanks david jencks
Help with car-maven-plugin site generation needed
I thought I might try to document the c-m-p a bit but when I try to run mvn site the javadoc plugin complains that I'm not using jdk 1.4 syntax. I tried everything I could think of to set source1.5/source but with no success whatsoever. If anyone has a clue how to fix this please demonstrate! btw I'm using maven 2.0.7 and wonder if we should make that a requirement. thanks david jencks
Re: Help with car-maven-plugin site generation needed
I will have a look As soon as I get back online. Got a new fancy airport extreme And well it was soo easy that I managed to *uck it all up --jason -Original Message- From: David Jencks [EMAIL PROTECTED] Date: Sat, 8 Sep 2007 00:25:30 To:Geronimo Dev List (JIRA) dev@geronimo.apache.org Subject: Help with car-maven-plugin site generation needed I thought I might try to document the c-m-p a bit but when I try to run mvn site the javadoc plugin complains that I'm not using jdk 1.4 syntax. I tried everything I could think of to set source1.5/source but with no success whatsoever. If anyone has a clue how to fix this please demonstrate! btw I'm using maven 2.0.7 and wonder if we should make that a requirement. thanks david jencks
[BUILD] Trunk: Failed for Revision: 573798
OpenEJB trunk at 573796
Geronimo Revision: 573798 built with tests included
See the full build-0400.log file at
http://people.apache.org/~prasad/binaries/trunk/20070908/build-0400.log
typejar/type
/dependency
obsoletes
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/obsoletes
source-repositoryhttp://foo.com/source-repository
source-repositoryhttp://bar.com/source-repository
copy-file relative-to=WEB-INF
dest-dir=barMETA-INF/foo.xml/copy-file
config-xml-content
ns2:gbean
ns2:attribute
name=repositoryListhttp://geronimo.apache.org/plugins/plugin-repository-list-2.1.txt/ns2:attribute
ns2:attribute
name=userRepositories~/.m2/repository,${key1}/ns2:attribute
/ns2:gbean
/config-xml-content
artifact-alias
key=org.apache.geronimo.test/foo//carorg.apache.geronimo.test/bar/1.0/car/artifact-alias
config-substitution key=key2value2/config-substitution
config-substitution key=key1value1/config-substitution
/plugin-artifact
/geronimo-plugin
, found = ?xml version=1.0 encoding=UTF-8 standalone=yes?
geronimo-plugin xmlns=http://geronimo.apache.org/xml/ns/plugins-1.3;
xmlns:ns2=http://geronimo.apache.org/xml/ns/attributes-1.2;
nameGeronimo Maven2 Plugins :: CAR/name
categoryTest/category
descriptionApache Geronimo, the JavaEE server project of the Apache
Software Foundation./description
urlhttp://geronimo.apache.org//url
authorThe Apache Geronimo development community/author
license osi-approved=trueThe Apache Software License, Version
2.0/license
plugin-artifact
module-id
groupIdorg.apache.geronimo.plugins.it/groupId
artifactIdcar-maven-plugin/artifactId
version2.1-SNAPSHOT/version
typejar/type
/module-id
jvm-version1.5/jvm-version
jvm-version1.5.2/jvm-version
prerequisite
id
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/id
resource-typejoke/resource-type
descriptionthis is an explanation/description
/prerequisite
dependency start=true
groupIdvelocity/groupId
artifactIdvelocity/artifactId
version1.4/version
typejar/type
/dependency
dependency start=true
groupIdxstream/groupId
artifactIdxstream/artifactId
version1.1.3/version
typejar/type
/dependency
obsoletes
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/obsoletes
source-repositoryhttp://foo.com/source-repository
source-repositoryhttp://bar.com/source-repository
copy-file relative-to=WEB-INF
dest-dir=barMETA-INF/foo.xml/copy-file
config-xml-content
ns2:gbean
ns2:attribute
name=repositoryListhttp://geronimo.apache.org/plugins/plugin-repository-list-2.1.txt/ns2:attribute
ns2:attribute
name=userRepositories~/.m2/repository,${key1}/ns2:attribute
/ns2:gbean
/config-xml-content
artifact-alias
key=org.apache.geronimo.test/foo//carorg.apache.geronimo.test/bar/1.0/car/artifact-alias
config-substitution key=key2value2/config-substitution
config-substitution key=key1value1/config-substitution
/plugin-artifact
/geronimo-plugin
; See
/home/prasad/geronimo/trunk/maven-plugins/car-maven-plugin/src/it/metadatageneration-2/build.log
for details
[INFO]
[INFO]
---
[INFO] Test Summary (0:00:31.272)
[INFO] Passed: 0
[INFO] Failed: 4
[INFO]
---
[INFO]
[INFO] The following builds failed:
[INFO] *
/home/prasad/geronimo/trunk/maven-plugins/car-maven-plugin/src/it/j2ee-system/pom.xml
[INFO] *
/home/prasad/geronimo/trunk/maven-plugins/car-maven-plugin/src/it/j2ee-system-2/pom.xml
[INFO] *
/home/prasad/geronimo/trunk/maven-plugins/car-maven-plugin/src/it/metadatageneration/pom.xml
[INFO] *
/home/prasad/geronimo/trunk/maven-plugins/car-maven-plugin/src/it/metadatageneration-2/pom.xml
[INFO]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] 4 of 4 builds failed
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 14 minutes 16 seconds
[INFO] Finished at: Sat Sep 08 04:28:12 EDT 2007
[INFO] Final Memory: 133M/508M
[INFO]
Re: [BUILD] Trunk: Failed for Revision: 573798
I've fixed this...
Seems like the new integration tests for the car-maven-plugin's
geronimo-plugin.xml validate bits are ***VERY*** sensitive to the
changes in the build configuration.
This broke because I changed the top-level pom's description from:
Apache Geronimo, the J2EE server project of the Apache Software
Foundation.
to:
Apache Geronimo, the JavaEE server project of the Apache
Software Foundation.
* * *
I've not looked at the new car-m-p changes that recently went in...
but I'm not sure that they should be pulling in descriptions from the
projects pom... should they? Uh, I dunno...
Anyways... fixed now :-)
--jason
On Sep 8, 2007, at 1:30 AM, [EMAIL PROTECTED] wrote:
OpenEJB trunk at 573796
Geronimo Revision: 573798 built with tests included
See the full build-0400.log file at http://people.apache.org/
~prasad/binaries/trunk/20070908/build-0400.log
typejar/type
/dependency
obsoletes
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/obsoletes
source-repositoryhttp://foo.com/source-repository
source-repositoryhttp://bar.com/source-repository
copy-file relative-to=WEB-INF dest-dir=barMETA-INF/
foo.xml/copy-file
config-xml-content
ns2:gbean
ns2:attribute name=repositoryListhttp://
geronimo.apache.org/plugins/plugin-repository-list-2.1.txt/
ns2:attribute
ns2:attribute name=userRepositories~/.m2/
repository,${key1}/ns2:attribute
/ns2:gbean
/config-xml-content
artifact-alias key=org.apache.geronimo.test/foo//
carorg.apache.geronimo.test/bar/1.0/car/artifact-alias
config-substitution key=key2value2/config-substitution
config-substitution key=key1value1/config-substitution
/plugin-artifact
/geronimo-plugin
, found = ?xml version=1.0 encoding=UTF-8 standalone=yes?
geronimo-plugin xmlns=http://geronimo.apache.org/xml/ns/
plugins-1.3 xmlns:ns2=http://geronimo.apache.org/xml/ns/
attributes-1.2
nameGeronimo Maven2 Plugins :: CAR/name
categoryTest/category
descriptionApache Geronimo, the JavaEE server project of the
Apache Software Foundation./description
urlhttp://geronimo.apache.org//url
authorThe Apache Geronimo development community/author
license osi-approved=trueThe Apache Software License,
Version 2.0/license
plugin-artifact
module-id
groupIdorg.apache.geronimo.plugins.it/groupId
artifactIdcar-maven-plugin/artifactId
version2.1-SNAPSHOT/version
typejar/type
/module-id
jvm-version1.5/jvm-version
jvm-version1.5.2/jvm-version
prerequisite
id
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/id
resource-typejoke/resource-type
descriptionthis is an explanation/description
/prerequisite
dependency start=true
groupIdvelocity/groupId
artifactIdvelocity/artifactId
version1.4/version
typejar/type
/dependency
dependency start=true
groupIdxstream/groupId
artifactIdxstream/artifactId
version1.1.3/version
typejar/type
/dependency
obsoletes
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/obsoletes
source-repositoryhttp://foo.com/source-repository
source-repositoryhttp://bar.com/source-repository
copy-file relative-to=WEB-INF dest-dir=barMETA-INF/
foo.xml/copy-file
config-xml-content
ns2:gbean
ns2:attribute name=repositoryListhttp://
geronimo.apache.org/plugins/plugin-repository-list-2.1.txt/
ns2:attribute
ns2:attribute name=userRepositories~/.m2/
repository,${key1}/ns2:attribute
/ns2:gbean
/config-xml-content
artifact-alias key=org.apache.geronimo.test/foo//
carorg.apache.geronimo.test/bar/1.0/car/artifact-alias
config-substitution key=key2value2/config-substitution
config-substitution key=key1value1/config-substitution
/plugin-artifact
/geronimo-plugin
; See /home/prasad/geronimo/trunk/maven-plugins/car-maven-plugin/
src/it/metadatageneration-2/build.log for details
[INFO]
[INFO]
--
-
[INFO] Test Summary (0:00:31.272)
[INFO] Passed: 0
[INFO] Failed: 4
[INFO]
--
-
[INFO]
[INFO] The following builds failed:
[INFO] * /home/prasad/geronimo/trunk/maven-plugins/car-maven-
plugin/src/it/j2ee-system/pom.xml
[INFO] * /home/prasad/geronimo/trunk/maven-plugins/car-maven-
plugin/src/it/j2ee-system-2/pom.xml
[INFO] * /home/prasad/geronimo/trunk/maven-plugins
[jira] Commented: (GERONIMODEVTOOLS-193) Runs ping and throws java.lang.SecurityException during Geronimo server startup.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525913 ] Kan Ogawa commented on GERONIMODEVTOOLS-193: Traced root cause stack trace of the java.lang.SecurityException: Booting Geronimo Kernel (in Java 1.5.0_11)... Module 1/33 org.apache.geronimo.configs/rmi-naming/2.0.1/car started in 1.985s Module 2/33 org.apache.geronimo.configs/j2ee-server/2.0.1/car started in 1.281s Module 3/33 org.apache.geronimo.configs/transaction/2.0.1/car started in 2.859s Module 4/33 org.apache.geronimo.configs/j2ee-security/2.0.1/car started in .000s Module 5/33 org.apache.geronimo.configs/axis/2.0.1/car javax.security.auth.login.LoginException: No LoginModules configured for geronimo-admin at javax.security.auth.login.LoginContext.init(LoginContext.java:256) at javax.security.auth.login.LoginContext.init(LoginContext.java:403) at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:67) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:214) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) javax.security.auth.login.LoginException: No LoginModules configured for geronimo-admin at javax.security.auth.login.LoginContext.init(LoginContext.java:256) at javax.security.auth.login.LoginContext.init(LoginContext.java:403) at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:67) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:214) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) Why does the LoginContext initialization fail ? Runs ping and throws java.lang.SecurityException during Geronimo server startup. Key: GERONIMODEVTOOLS-193 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-193 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Windows XP, Eclipse 3.3, WTP 2.0, Geronimo server 2.0.1, Sun JDK 1.5.0_11 Reporter: Kan Ogawa Assignee: Tim McConnell Hi, While launching Geronimo server on Eclipse, a ping runs in async and the server startup sometimes fails. This server hostname is localhost. Eclipse error log: java.lang.SecurityException: Invalid login at org.apache.geronimo.jmxremoting.Authenticator.authenticate(Authenticator.java:73) at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:214) at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at
Re: Help with car-maven-plugin site generation needed
The javadoc-plugin configuration in genesis in set to use jdk 1.4. Rebuild genesis/configs/project-config by changing the javadoc-plugin configuration in it to use jdk 1.5. Then run site at c-m-p. This should fix it. Cheers Prasad On 9/8/07, David Jencks [EMAIL PROTECTED] wrote: I thought I might try to document the c-m-p a bit but when I try to run mvn site the javadoc plugin complains that I'm not using jdk 1.4 syntax. I tried everything I could think of to set source1.5/source but with no success whatsoever. If anyone has a clue how to fix this please demonstrate! btw I'm using maven 2.0.7 and wonder if we should make that a requirement. thanks david jencks
[jira] Commented: (GERONIMO-3457) Drools BRMS issue using geronimo 2.0.1-jetty6
[ https://issues.apache.org/jira/browse/GERONIMO-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525920 ] Kevan Miller commented on GERONIMO-3457: K. I'm not seeing a redirect problem on 4.0.1, either. I'm deploying the WAR as is on an unaltered 2.0.1 Jetty server. I have seen an intermittent error logged on the server. Seems to only occur w/ Safari. All seems to work even when I see the error: org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:760) at org.mortbay.jetty.HttpGenerator.complete(HttpGenerator.java:646) at org.mortbay.jetty.HttpConnection.commitResponse(HttpConnection.java:584) at org.mortbay.jetty.HttpConnection$Output.sendContent(HttpConnection.java:965) at org.mortbay.jetty.servlet.DefaultServlet.sendData(DefaultServlet.java:655) at org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:416) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093) at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:56) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:313) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:613) Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104) at sun.nio.ch.IOUtil.write(IOUtil.java:60) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:302) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:166) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:208) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:271) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:198) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:685) ... 36 more 10:16:44,869 WARN [log] /drools-jbrms/org.drools.brms.JBRMS/welcome.html: org.mortbay.jetty.EofException Drools BRMS issue using geronimo 2.0.1-jetty6 - Key: GERONIMO-3457 URL: https://issues.apache.org/jira/browse/GERONIMO-3457 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects
Fwd: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/
FYI, the Tomcat team decided to move tomcat/trunk to sandbox while details over RTC vs. CTR and their comet implementation are being resolved. The Geronimo 2.x Tomcat assemblies use a patched version of what was in tomcat/trunk for the enhanced annotation support. See https://issues.apache.org/jira/browse/GERONIMO-3206 for details on how Geronimo's patched version of Tomcat is built. I raised a concern about moving trunk to sandbox since it's the only branch that contains the annotation support needed by Geronimo. A committer responded that he will think about maintaining a patchset with this annotation support. See http://tinyurl.com/2enw25 Best wishes, Paul Begin forwarded message: From: [EMAIL PROTECTED] Date: September 7, 2007 10:35:34 PM EDT To: [EMAIL PROTECTED] Subject: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/ Reply-To: Tomcat Developers List [EMAIL PROTECTED] Author: fhanik Date: Fri Sep 7 19:35:33 2007 New Revision: 573772 URL: http://svn.apache.org/viewvc?rev=573772view=rev Log: (empty) Added: tomcat/sandbox/gdev6x/ - copied from r573771, tomcat/trunk/ Removed: tomcat/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Welcome Shiva Kumar H R as Apache Geronimo's latest committer
Hi Shiva, Congrats Regards Manu On 9/8/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi All, The Geronimo PMC is pleased to announce that Shiva Kumar H R has recently accepted our invitation to become an Apache Geronimo committer. Shiva has been contributing to Geronimo for quite sometime and is very active on lists. His Eclipse Plugin Development skill is awesome and I am sure he will take our Geronimo DEVTOOLS project to new heights. We're thrilled to hand him a committer hat and look forward to his continued contributions to the project. Congratulations and welcome aboard, Shiva! -Vamsi
Re: [ANNOUNCE] Welcome Shiva Kumar H R as Apache Geronimo's latest committer
Welcome Shiva! Best wishes, Paul On Sep 7, 2007, at 5:32 PM, Vamsavardhana Reddy wrote: Hi All, The Geronimo PMC is pleased to announce that Shiva Kumar H R has recently accepted our invitation to become an Apache Geronimo committer. Shiva has been contributing to Geronimo for quite sometime and is very active on lists. His Eclipse Plugin Development skill is awesome and I am sure he will take our Geronimo DEVTOOLS project to new heights. We're thrilled to hand him a committer hat and look forward to his continued contributions to the project. Congratulations and welcome aboard, Shiva! -Vamsi
[jira] Created: (GERONIMODEVTOOLS-196) Maven DependencySet wildcards not working on all platforms (e.g., Mac OS)
Maven DependencySet wildcards not working on all platforms (e.g., Mac OS) - Key: GERONIMODEVTOOLS-196 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-196 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Plugin stuff
Wow, this all looks great! Now that the underlying stuff is more stabilized and functionally complete I can help bring the admin console up to date. I think the CLI might also need some touching up. One question I have is should we keep the reference to: http://www.geronimoplugins.com/repository/geronimo-1.1/ in the default source-repositories listed in configs/pom.xml? I don't know if there are any plans to provide a repository of geronimo's 2.x plugin artifacts or their dependencies from that location. If there plans for that then we should leave the reference in place (the more repos the better, I say) but may need to update the geronimo version number in the URL. I'm also thinking we should add a reference to: http://geronimo.apache.org/plugins/geronimo-2.1/ in the source-repo list in configs/pom.xml and update that URL as we increment the server version and create new repos. Or maybe we should start using a single repo and URL for all versions of geronimo since GERONIMO-3330 has been implemented. Now that the catalog schema provides this flexibility we can decide how to use it - one repo and catalog for supporting multiple versions of geronimo or a repo for each version. We have discussed some pros and cons of both options. I'm pretty sure that plugin repos like the one at geronimo.liferay.com will want to use a single repo since its easier to update and maintain the catalog. But for our server plugins we may want to have a repo per version since the car maven plugin can automagically create the catalog (very cool feature). Best wishes, Paul On Sep 7, 2007, at 8:00 PM, David Jencks wrote: I think the plugin installer stuff might be pretty much functionally complete. In the plugin-config.xml you can specify bits of config.xml, artifact_aliases.properties, and config-substitutions.properties. I think this might be enough installation stuff to build a server. The car-maven-plugin now: - constructs the geronimo-plugin.xml and processes the plan.xml. - dependencies can be from the maven dependencies with or without versions (all compile and runtime dependencies in the current pom are included) - or dependencies can be explicitly specified in the c-m-p configuration. - bits like name, descriptions, licesnes, url, moduleId are derived from the pom with normal maven inheritance. - everything else in the geronimo-plugin.xml is derived from a template in the pom. There are 2 of these: a commonInstance you can put in a parent pom that provides defaults, and an instance that you put in the pom itself. Collections in the instance replace rather than add to stuff specified in the commonInstance. Both of these follow the plugin-artifactType but you can leave out xml namespaces. Don't have more than one of instance or commonInstance in any sequence of pom ancestors: maven interpolation doesn't work on these and will break whatever you are trying to do. - when you build a car, the plugin will update ~/.m2/repository/ geronimo-plugins.xml with the new geronimo-plugin.xml information. - to construct an entirely new geronimo-plugins.xml in your local maven repo run mvn org.apache.geronimo.plugins:car-maven-plugin:create-pluginlist I've set the default repo list to include this in the local maven repo for the jetty javaee assembly on osx. I'd like it if someone with a windows setup could test if it works on windows as well. Then we can update the tomcat configuration. To test, update and build trunk, start the jetty javaee server, and on a separate console window run java -jar bin/deployer.jar search-plugins You should see the local maven repo listed and if you select it you should see all the cars in the server listed. The stuff in the admin console works a little bit but still needs some TLC from someone with a clue about UIs. thanks david jencks On Sep 3, 2007, at 10:55 AM, David Jencks wrote: I've committed what I have so far: - use new plugin schema - generate geronimo-plugin.xml files for each car from pom.xml - generate plan environment section from explicitly listed car- maven-plugin configuration instead of from maven dependencies. We check that each dependency listed in the maven plugin config is actually present in the maven dependencies section. - moved car plans to src/main/plan/plan.xml - include plan in the car for reference. Problems/left to do: - I haven't converted many of the car poms to actually generate the correct geronimo-plugin.xml or the correct plan, so most plans have the previously generated dependencies in them. There are a lot (nearly 100) so if anyone wants to help me update the poms that would be great. I did do a few of the cars with existing geronimo-plugin.xmls. - the xml configuration format in pom.xml is adapted for maven, not for jaxb. It would be great if we could figure out how to make the configuration in pom.xml
Re: New GShell-based Geronimo Server launcher now in server/trunk
Aighty, well... I've done some long awaited re-factoring, and while its still not _perfect_ its a whole lot better now IMO I think from a framework perspective that its probably mature enough to take on the task of being the server bootloader. I'm going to continue to refactor the guts of GShell over time, of course... but I think that what is there now is highly usable for a simple platform independent launcher, as well as for porting over the other cli bits we have. I've done a lot of work in the past week, incase you didn't see the storm of scm messages... pulled out pico, plopped in plexus, pulled out commons-logging and commons-lang, which are suck and boated (in that order). I've gotten the basic framework and supported classes to use GShell down to ~ 1mb (a wee bit under)... though when I started to add the layout.xml abstraction stuff, I had to pull in xstream which bloated her back up to ~1.4m. I may eventually fix that... or not, cause xstream is s very handy for xml - object stuff. I've fallen in love with annotations... they are *ucking great. They work really well for handling the cli option and argument muck which most every command needs to do. And striping out the insano-sucking commons-cli really simplified command implementations dramatically IMO. Anyways... I've make a heck of a lot of progress on cleaning up the GShell framework... and more is to come I'm sure... But for now, I think its probably ready for use primetime as the Geronimo Server's bootloader. I think this provides a some significant value... 1) Platform scripts become consistent and relatively simple, easy to maintain 2) Everyone will now have a consist way of launching the server, even if you like a .sh, .bat, or java -jar, then end process that is launched will be the same for everyone. 3) Opens up the door for some really nice and fancy fancy management muck (like restarting the server from the web console, or cloning a server instance or backing up a server instance...) 4) Lays the ground work for future features, like cluster management, remote administration and scripting... * * * So, I think its time to decide... are we a go or no go for GShell as the core CLI for Geronimo thingys and even more important, are we go or no go for using GShell to boot up the server process? --jason
Re: [ANNOUNCE] Welcome Shiva Kumar H R as Apache Geronimo's latest committer
Congrats Shiva! Welcome aboard! Jacek On 9/7/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi All, The Geronimo PMC is pleased to announce that Shiva Kumar H R has recently accepted our invitation to become an Apache Geronimo committer. Shiva has been contributing to Geronimo for quite sometime and is very active on lists. His Eclipse Plugin Development skill is awesome and I am sure he will take our Geronimo DEVTOOLS project to new heights. We're thrilled to hand him a committer hat and look forward to his continued contributions to the project. Congratulations and welcome aboard, Shiva! -Vamsi -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: New GShell-based Geronimo Server launcher now in server/trunk
A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/ gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/ gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver listening on 9443 (over ssl of course). Or how about you want to reboot a server remotely? someserver:9447 restart-server now Geronimo server shutting down... Geronimo server shutdown. Geronimo server starting... ... Geronimo server started in ... Since GShell manages the processes its really easy to perform a full restart of a Server w/o needing magical platform scripting muck. And it will just work the same on each platform too. Once we have clustering, then we can do the same kinda thing for an entire cluster of nodes... someserver:9447 restart-cluster now
Re: New GShell-based Geronimo Server launcher now in server/trunk
Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/ gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/ gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver listening on 9443 (over ssl of course). Or how about you want to reboot a server remotely? someserver:9447 restart-server now Geronimo server shutting down... Geronimo server shutdown. Geronimo server starting... ... Geronimo server started in ... Since GShell manages the processes its really easy to perform a full restart of a Server w/o needing magical platform scripting muck. And it will just work the same on each platform too. Once we
[jira] Assigned: (GERONIMO-2188) When oracle wrapper is used, commits are not immediately committed to oracle database
[ https://issues.apache.org/jira/browse/GERONIMO-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reassigned GERONIMO-2188: - Assignee: David Jencks (was: Lin Sun) David, could ou look at it and get it committed to tranql? Thanks. Lin When oracle wrapper is used, commits are not immediately committed to oracle database - Key: GERONIMO-2188 URL: https://issues.apache.org/jira/browse/GERONIMO-2188 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1 Reporter: Krishnakumar B Assignee: David Jencks Attachments: G2188-2.patch, G2188-latest.patch, G2188.patch We have to configure CommitBeforeAutCommit=true property exclusively in the database connection pool plan, to have the ejb -based transactions immediately committed for oracle database. Otherwise it only commits transaction when the server shuts-down. This problem is not faces with Derby database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-196) Maven DependencySet wildcards not working on all platforms (e.g., Mac OS)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525949 ] Tim McConnell commented on GERONIMODEVTOOLS-196: Updated Deployable.xml and UpdateSite.xml with revision 573900 to address this problem. Waiting on verification that it works on platforms other than Windows before closing Maven DependencySet wildcards not working on all platforms (e.g., Mac OS) - Key: GERONIMODEVTOOLS-196 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-196 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Welcome Shiva Kumar H R as Apache Geronimo's latest committer
Welcome and congratulations Shiva !! Jay D. McHugh wrote: Congratulations Shiva! Jay Vamsavardhana Reddy wrote: Hi All, The Geronimo PMC is pleased to announce that Shiva Kumar H R has recently accepted our invitation to become an Apache Geronimo committer. Shiva has been contributing to Geronimo for quite sometime and is very active on lists. His Eclipse Plugin Development skill is awesome and I am sure he will take our Geronimo DEVTOOLS project to new heights. We're thrilled to hand him a committer hat and look forward to his continued contributions to the project. Congratulations and welcome aboard, Shiva! -Vamsi -- Thanks, Tim McConnell
[jira] Created: (GERONIMODEVTOOLS-197) Mechanism required to
Mechanism required to -- Key: GERONIMODEVTOOLS-197 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-197 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.0 Per suggestions from David Jencks there seems to be a couple alternatives to consider (maven-rat-plugin or the maven-remote-resources-plugin) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New GShell-based Geronimo Server launcher now in server/trunk
Ya, should be simple enough... though I don't want to keep maintaining these extra assemblies, I'd like to just convert all of the assemblies to use this stuff... But if it helps ya out, I can make a geronimo-tomcat6-javaee5-gshell... --jason On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote: Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../ lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/ gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver listening on 9443 (over ssl of course). Or how about you want to reboot a server remotely? someserver:9447 restart-server now Geronimo server shutting down...
Re: New GShell-based Geronimo Server launcher now in server/trunk
On Sep 8, 2007, at 1:46 PM, Jason Dillon wrote: Ya, should be simple enough... though I don't want to keep maintaining these extra assemblies, I'd like to just convert all of the assemblies to use this stuff... I was convinced this was the way to go after trying the first jetty- gshell a couple weeks ago. thanks david jencks But if it helps ya out, I can make a geronimo-tomcat6-javaee5- gshell... --jason On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote: Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/ gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver
[jira] Commented: (GERONIMO-2188) When oracle wrapper is used, commits are not immediately committed to oracle database
[ https://issues.apache.org/jira/browse/GERONIMO-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525959 ] David Jencks commented on GERONIMO-2188: I'm confused since it looks to me as if I applied these changes to tranql/connector trunk a long time ago. What did you want me to apply this patch to? thanks When oracle wrapper is used, commits are not immediately committed to oracle database - Key: GERONIMO-2188 URL: https://issues.apache.org/jira/browse/GERONIMO-2188 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1 Reporter: Krishnakumar B Assignee: David Jencks Attachments: G2188-2.patch, G2188-latest.patch, G2188.patch We have to configure CommitBeforeAutCommit=true property exclusively in the database connection pool plan, to have the ejb -based transactions immediately committed for oracle database. Otherwise it only commits transaction when the server shuts-down. This problem is not faces with Derby database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-4) Settings, read from ~/.gshell/...
[ https://issues.apache.org/jira/browse/GSHELL-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-4. - Resolution: Fixed We've now to privative support to read from: * ~/.gshell/gshell.profile (non-interactive shells) * ~/.gshell/gshell.rc (interactive shells) Will eventually abstract the filenames to a branding/layout component... but for now they are hardcoded. Settings, read from ~/.gshell/... - Key: GSHELL-4 URL: https://issues.apache.org/jira/browse/GSHELL-4 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Core Affects Versions: 0.0.1 Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-7) ANSI color prompt
[ https://issues.apache.org/jira/browse/GSHELL-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-7. - Resolution: Fixed I've hooked up up the ANSI RenderWriter as to the default IO bits so ANSI formats like @|red foo| whatever should work find from and usage of io.out/err ANSI color prompt - Key: GSHELL-7 URL: https://issues.apache.org/jira/browse/GSHELL-7 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Core Affects Versions: 0.0.1 Reporter: Jason Dillon Assignee: Jason Dillon Priority: Trivial Fix For: 1.0-alpha-1 Also create ANSI color G-logo (ANSI-art style), hook up to default with welcome.gsh? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-12) Global category *
[ https://issues.apache.org/jira/browse/GSHELL-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-12. -- Resolution: Won't Fix Categories are old news, the latest dealio is the layout... so this supersedes any category muck. Global category * --- Key: GSHELL-12 URL: https://issues.apache.org/jira/browse/GSHELL-12 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Core Affects Versions: 0.0.1 Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-1 * means global for category -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-11) Enable/disable categories.
[
https://issues.apache.org/jira/browse/GSHELL-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed GSHELL-11.
--
Resolution: Won't Fix
Categories are old news, the latest dealio is the layout... so this supersedes
any category muck.
Enable/disable categories.
--
Key: GSHELL-11
URL: https://issues.apache.org/jira/browse/GSHELL-11
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Core
Affects Versions: 0.0.1
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.0-alpha-1
Command def sets the initial state, 'enable' command toggles to enable or
disable categories:
{noformat}
# enable all categories ending with debug
/gshell/debug *debug
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-198) Daytrader deployment exception in Eclipse
Daytrader deployment exception in Eclipse - Key: GERONIMODEVTOOLS-198 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-198 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tim McConnell Assignee: Tim McConnell Priority: Minor Fix For: 2.0 There is a deployment exception occurring in Eclipse when deploying Daytrader, although it seems to be fairly benign since Daytrader ultimately does deploy and seems to function correctly. Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/31 org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car started in 1.453s Module 2/31 org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car started in .359s Module 3/31 org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car started in .875s Module 4/31 org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car started in .000s Module 5/31 org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car INFO - Configuring Service(id=Default MDB Container, type=Container, provider-id=Default MDB Container) INFO - Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container) INFO - Configuring app: jar:file:/C:/TEMP/TRUNK/TC/repository/org/apache/geronimo/modules/geronimo-openejb/2.1-SNAPSHOT/geronimo-openejb-2.1-SNAPSHOT.jar!/org/apache/geronimo/openejb/ INFO - Loaded Module: jar:file:/C:/TEMP/TRUNK/TC/repository/org/apache/geronimo/modules/geronimo-openejb/2.1-SNAPSHOT/geronimo-openejb-2.1-SNAPSHOT.jar!/org/apache/geronimo/openejb/ INFO - Assembling app: jar:file:/C:/TEMP/TRUNK/TC/repository/org/apache/geronimo/modules/geronimo-openejb/2.1-SNAPSHOT/geronimo-openejb-2.1-SNAPSHOT.jar!/org/apache/geronimo/openejb/ INFO - Jndi(name=MEJBGBean/MEJB/javax.management.j2ee.ManagementHome) INFO - Created Ejb(deployment-id=MEJBGBean/MEJB, ejb-name=MEJB, container=Default Stateless Container) INFO - Configuring Service(id=Default Stateful Container, type=Container, provider-id=Default Stateful Container) INFO - Configuring Service(id=Default BMP Container, type=Container, provider-id=Default BMP Container) INFO - Configuring Service(id=Default CMP Container, type=Container, provider-id=Default CMP Container) started in 11.328s Module 6/31 org.apache.geronimo.configs/j2ee-corba-yoko/2.1-SNAPSHOT/car started in 1.782s Module 7/31 org.apache.geronimo.configs/system-database/2.1-SNAPSHOT/car started in .000s Module 8/31 org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car started in .000s Module 9/31 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car started in .000s Module 10/31 org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car started in .000s Module 11/31 org.apache.geronimo.configs/myfaces/2.1-SNAPSHOT/car started in .016s Module 12/31 org.apache.geronimo.configs/tomcat6/2.1-SNAPSHOT/car ERROR - Restricted listeners property file not found started in 3.172s Module 13/31 org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/carstarted in .844s Module 14/31 org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car started in .516s Module 15/31 org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car started in .234s Module 16/31 org.apache.geronimo.configs/persistence-jpa10-deployer/2.1-SNAPSHOT/car started in .172s Module 17/31 org.apache.geronimo.configs/openejb-deployer/2.1-SNAPSHOT/car started in .219s Module 18/31 org.apache.geronimo.configs/client-deployer/2.1-SNAPSHOT/car started in .250s Module 19/31 org.apache.geronimo.configs/axis2-deployer/2.1-SNAPSHOT/car started in .312s Module 20/31 org.apache.geronimo.configs/axis-deployer/2.1-SNAPSHOT/car started in 1.672s Module 21/31 org.apache.geronimo.configs/javamail/2.1-SNAPSHOT/car started in .125s Module 22/31 org.apache.geronimo.configs/sharedlib/2.1-SNAPSHOT/car started in .015s Module 23/31 org.apache.geronimo.configs/tomcat6-deployer/2.1-SNAPSHOT/car started in .187s Module 24/31 org.apache.geronimo.configs/jasper-deployer/2.1-SNAPSHOT/car started in .063s Module 25/31 org.apache.geronimo.configs/myfaces-deployer/2.1-SNAPSHOT/car started in .078s Module 26/31 org.apache.geronimo.configs/welcome-tomcat/2.1-SNAPSHOT/car started in .531s Module 27/31 org.apache.geronimo.configs/dojo-tomcat/2.1-SNAPSHOT/car started in .219s Module 28/31 org.apache.geronimo.configs/webconsole-tomcat/2.1-SNAPSHOT/car started in 3.719s Module 29/31
